From david.holmes at oracle.com Mon Aug 1 00:58:53 2022 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Aug 2022 10:58:53 +1000 Subject: Massive slowdown in regex processing while GC log fills with ICBufferFull messages In-Reply-To: <48755CD4-2A8B-471B-865F-FACE080213A9@kungfoocoder.org> References: <48755CD4-2A8B-471B-865F-FACE080213A9@kungfoocoder.org> Message-ID: <0a11a64d-2449-0eb4-fee4-a1e24b1b944c@oracle.com> Hi Paul, Redirecting to hotspot-dev as this issue is not likely to get much visibility on jdk-updates-dev. Probably worth filing an issue in bugs.openjdk.org if you can. Cheers, David On 1/08/2022 10:37 am, Paul Wagland wrote: > Hi all, > > We have been running into a problem with Java 17.0.1, 17.0.2, and now > 17.0.3. > > # java --version > openjdk 17.0.3 2022-04-19 > OpenJDK Runtime Environment Temurin-17.0.3+7 (build 17.0.3+7) > OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (build 17.0.3+7, mixed mode, > sharing) > > > The issue that we are seeing is very similar in behaviour to > https://bugs.openjdk.org/browse/JDK-8277212 > , with a couple of notable > exceptions: > 1. We are seeing this issue in 17.0.3, whereas JDK-8277212 was resolved > in either 17.0.2 or 17.0.3-oracle. > 2. We are using G1GC, not ZGC > > Unfortunately, we don?t know how to reproduce this issue, we are seeing > it happen about once a week across our fleet. We have about 300 > instances of Java running various different workloads. > > What happens is that on a machine where this occurs, after a period of > time we see CPU usage suddenly spike, and the gc logs suddenly start > getting flooded with ICBufferFull messages, at the rate of about 430 a > second. When doing thread dumps to see what is happening at that time, > we find most threads end up very deep in a regex processing stack, > unfortunately we have one of these fairly central to the product, so > this ends up affecting most threads. It seems that almost everything > that isn?t thread parsing operates at, or near to, full speed. This is > one of the reasons that this feels similar to JDK-8277212, since that > was mashing the VTABLES, and because of the way that regexes work, they > would appear to use a lot of VTABLE lookups, so any slowdown in that > area, is likely to affect them greatly. Note that this is pure > supposition, and I would love to know if there is any way if we can > prove, or disprove this, either via testing, or additional logging. > > Unfortunately, as mentioned above, we are not able to reproduce this in > our test environments, and we are only seeing this in customer > environments, and then not with any clearly identifiable cause. We have > seen the issue about a dozen times, over 17.0.1, 17.0.2, and recently, > 17.0.3. > > We have done some performance testing, and during the slow-down we get, > for our regex processing test: > > 10 iterations of testString 1 took 10700ms (1070004460ns/match) > (matched=false) > 10 iterations of testString 2 took 8965ms (896560879ns/match) (matched=true) > > Normal timings looks like: > 18503 iterations of testString 1 took 1000ms (54047ns/match) (matched=false) > 40954 iterations of testString 2 took 1000ms (24417ns/match) (matched=true) > > So that represents a slowdown of roughly 20,000 times! > > We have another test that is mostly map lookup heavy, and during the > high CPU it has: > doMapOperations:2:31076ns > doMapOperations:3:16951ns > doMapOperations:4:14192ns > > While normally it has: > doMapOperations:2:27392ns > doMapOperations:3:7987ns > doMapOperations:4:6079ns > > So a slowdown of maybe a factor of 2, which is perfectly explainable by > the very high CPU/system load. > > Our startup arguments are: > > JVM startup arguments: > -javaagent:/opt/jmx-exporter/jmx-exporter.jar=9404:/opt/jmx-exporter/config.yaml > --add-opens=java.base/java.lang=ALL-UNNAMED > --add-opens=java.base/java.io =ALL-UNNAMED > --add-opens=java.base/java.util=ALL-UNNAMED > --add-opens=java.base/java.util.concurrent=ALL-UNNAMED > --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED > -Dnop > -Djava.security.egd=file:/dev/./urandom > -XX:+HeapDumpOnOutOfMemoryError > -XX:HeapDumpPath=/opt/?/logs > -Djava.awt.headless=true > -XX:+PrintFlagsFinal > -DRP_CONTEXTPATH= > -DRP_UNPACKWAR=true > -XX:FlightRecorderOptions=stackdepth=256 > -XX:+UnlockDiagnosticVMOptions > -XX:+DebugNonSafepoints > -Xlog:gc*,safepoint=info:file=/opt/?/logs/verbosegc.log:time,uptimemillis:filecount=10,filesize=50M > -Xlog:class*=info:file=/opt/?/logs/classload.log:time,uptimemillis,level,tags:filecount=10,filesize=50M > -XX:+UseG1GC > -XX:G1PeriodicGCInterval=10000 > -XX:+ParallelRefProcEnabled > -XX:MaxDirectMemorySize=25M > -XX:MaxMetaspaceSize=300M > -XX:MetaspaceSize=100M > -Xss1024K > -XX:ReservedCodeCacheSize=150M > -XX:+SegmentedCodeCache > -Xmx862m > -XX:MaxMetaspaceFreeRatio=20 > -XX:MinMetaspaceFreeRatio=5 > -XX:MaxHeapFreeRatio=40 > -XX:MinHeapFreeRatio=5 > -Djdk.nio.maxCachedBufferSize=8192 > -XX:SoftMaxHeapSize=646m > -Dlog4j2.disableJmx=true > -Djdk.tls.ephemeralDHKeySize=2048 > -Djava.protocol.handler.pkgs=org.apache.catalina.webresources > -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 > -Dignore.endorsed.dirs= > -Dcatalina.base=/opt/?/server1 > -Dcatalina.home=/opt/?/tomcat > -Djava.io.tmpdir=/opt/?/temp > > Can anyone think of anything that we can do to ameliorate this problem, > apart from not using regexes, which we are moving towards, but I think > that they are the victim here, not the cause of the problem, since in > normal use, they are ?fast enough?. > > If there is any information that I can add, please let me know! > > Cheers, > Paul From david.holmes at oracle.com Mon Aug 1 01:16:54 2022 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Aug 2022 11:16:54 +1000 Subject: Massive slowdown in regex processing while GC log fills with ICBufferFull messages In-Reply-To: <0a11a64d-2449-0eb4-fee4-a1e24b1b944c@oracle.com> References: <48755CD4-2A8B-471B-865F-FACE080213A9@kungfoocoder.org> <0a11a64d-2449-0eb4-fee4-a1e24b1b944c@oracle.com> Message-ID: <2640b7df-d4d3-979c-9c96-2a02fd7fe98a@oracle.com> https://bugs.openjdk.org/browse/JDK-8291596 David On 1/08/2022 10:58 am, David Holmes wrote: > Hi Paul, > > Redirecting to hotspot-dev as this issue is not likely to get much > visibility on jdk-updates-dev. > > Probably worth filing an issue in bugs.openjdk.org if you can. > > Cheers, > David > > > On 1/08/2022 10:37 am, Paul Wagland wrote: >> Hi all, >> >> We have been running into a problem with Java 17.0.1, 17.0.2, and now >> 17.0.3. >> >> # java --version >> openjdk 17.0.3 2022-04-19 >> OpenJDK Runtime Environment Temurin-17.0.3+7 (build 17.0.3+7) >> OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (build 17.0.3+7, mixed mode, >> sharing) >> >> >> The issue that we are seeing is very similar in behaviour to >> https://bugs.openjdk.org/browse/JDK-8277212 >> , with a couple of >> notable exceptions: >> 1. We are seeing this issue in 17.0.3, whereas JDK-8277212 was >> resolved in either 17.0.2 or 17.0.3-oracle. >> 2. We are using G1GC, not ZGC >> >> Unfortunately, we don?t know how to reproduce this issue, we are >> seeing it happen about once a week across our fleet. We have about 300 >> instances of Java running various different workloads. >> >> What happens is that on a machine where this occurs, after a period of >> time we see CPU usage suddenly spike, and the gc logs suddenly start >> getting flooded with ICBufferFull messages, at the rate of about 430 a >> second. When doing thread dumps to see what is happening at that time, >> we find most threads end up very deep in a regex processing stack, >> unfortunately we have one of these fairly central to the product, so >> this ends up affecting most threads. It seems that almost everything >> that isn?t thread parsing operates at, or near to, full speed. This is >> one of the reasons that this feels similar to JDK-8277212, since that >> was mashing the VTABLES, and because of the way that regexes work, >> they would appear to use a lot of VTABLE lookups, so any slowdown in >> that area, is likely to affect them greatly. Note that this is pure >> supposition, and I would love to know if there is any way if we can >> prove, or disprove this, either via testing, or additional logging. >> >> Unfortunately, as mentioned above, we are not able to reproduce this >> in our test environments, and we are only seeing this in customer >> environments, and then not with any clearly identifiable cause. We >> have seen the issue about a dozen times, over 17.0.1, 17.0.2, and >> recently, 17.0.3. >> >> We have done some performance testing, and during the slow-down we >> get, for our regex processing test: >> >> 10 iterations of testString 1 took 10700ms (1070004460ns/match) >> (matched=false) >> 10 iterations of testString 2 took 8965ms (896560879ns/match) >> (matched=true) >> >> Normal timings looks like: >> 18503 iterations of testString 1 took 1000ms (54047ns/match) >> (matched=false) >> 40954 iterations of testString 2 took 1000ms (24417ns/match) >> (matched=true) >> >> So that represents a slowdown of roughly 20,000 times! >> >> We have another test that is mostly map lookup heavy, and during the >> high CPU it has: >> doMapOperations:2:31076ns >> doMapOperations:3:16951ns >> doMapOperations:4:14192ns >> >> While normally it has: >> doMapOperations:2:27392ns >> doMapOperations:3:7987ns >> doMapOperations:4:6079ns >> >> So a slowdown of maybe a factor of 2, which is perfectly explainable >> by the very high CPU/system load. >> >> Our startup arguments are: >> >> JVM startup arguments: >> -javaagent:/opt/jmx-exporter/jmx-exporter.jar=9404:/opt/jmx-exporter/config.yaml >> >> --add-opens=java.base/java.lang=ALL-UNNAMED >> --add-opens=java.base/java.io? =ALL-UNNAMED >> --add-opens=java.base/java.util=ALL-UNNAMED >> --add-opens=java.base/java.util.concurrent=ALL-UNNAMED >> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED >> -Dnop >> -Djava.security.egd=file:/dev/./urandom >> -XX:+HeapDumpOnOutOfMemoryError >> -XX:HeapDumpPath=/opt/?/logs >> -Djava.awt.headless=true >> -XX:+PrintFlagsFinal >> -DRP_CONTEXTPATH= >> -DRP_UNPACKWAR=true >> -XX:FlightRecorderOptions=stackdepth=256 >> -XX:+UnlockDiagnosticVMOptions >> -XX:+DebugNonSafepoints >> -Xlog:gc*,safepoint=info:file=/opt/?/logs/verbosegc.log:time,uptimemillis:filecount=10,filesize=50M >> >> -Xlog:class*=info:file=/opt/?/logs/classload.log:time,uptimemillis,level,tags:filecount=10,filesize=50M >> >> -XX:+UseG1GC >> -XX:G1PeriodicGCInterval=10000 >> -XX:+ParallelRefProcEnabled >> -XX:MaxDirectMemorySize=25M >> -XX:MaxMetaspaceSize=300M >> -XX:MetaspaceSize=100M >> -Xss1024K >> -XX:ReservedCodeCacheSize=150M >> -XX:+SegmentedCodeCache >> -Xmx862m >> -XX:MaxMetaspaceFreeRatio=20 >> -XX:MinMetaspaceFreeRatio=5 >> -XX:MaxHeapFreeRatio=40 >> -XX:MinHeapFreeRatio=5 >> -Djdk.nio.maxCachedBufferSize=8192 >> -XX:SoftMaxHeapSize=646m >> -Dlog4j2.disableJmx=true >> -Djdk.tls.ephemeralDHKeySize=2048 >> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources >> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 >> -Dignore.endorsed.dirs= >> -Dcatalina.base=/opt/?/server1 >> -Dcatalina.home=/opt/?/tomcat >> -Djava.io.tmpdir=/opt/?/temp >> >> Can anyone think of anything that we can do to ameliorate this >> problem, apart from not using regexes, which we are moving towards, >> but I think that they are the victim here, not the cause of the >> problem, since in normal use, they are ?fast enough?. >> >> If there is any information that I can add, please let me know! >> >> Cheers, >> Paul From duke at openjdk.org Mon Aug 1 04:58:49 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Mon, 1 Aug 2022 04:58:49 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: - Add assertions - Fix marked logic - Erik refactorings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9655/files - new: https://git.openjdk.org/jdk/pull/9655/files/f77f44eb..5d26ab8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=00-01 Stats: 339 lines in 14 files changed: 85 ins; 144 del; 110 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From duke at openjdk.org Mon Aug 1 05:27:39 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Mon, 1 Aug 2022 05:27:39 GMT Subject: Integrated: 8290062: Remove nmethodLocker for nmethods on-stack In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 07:49:09 GMT, Axel Boldt-Christmas wrote: > From JBS: > >> The nmethodLocker is pretty nasty as it prevents an nmethod from being freed, but without really keeping it alive. We would like to minimize its use. The most obvious places where it can be removed, is when "protecting" nmethods that are already on-stack. Neither the sweeper nor the GC is interested in making nmethods on-stack not live. These ones simply do not do anything. > > Removed the `nmethodLocker` where the nmethod is a caller on the stack. > > Testing: tier1-7 This pull request has now been integrated. Changeset: 257c71c3 Author: Axel Boldt-Christmas Committer: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/257c71c35fa6f52a429347a9ed883498d613b5d5 Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod 8290062: Remove nmethodLocker for nmethods on-stack Reviewed-by: eosterlund, kvn ------------- PR: https://git.openjdk.org/jdk/pull/9444 From paul at kungfoocoder.org Mon Aug 1 06:28:25 2022 From: paul at kungfoocoder.org (Paul Wagland) Date: Mon, 1 Aug 2022 08:28:25 +0200 Subject: Massive slowdown in regex processing while GC log fills with ICBufferFull messages In-Reply-To: <2640b7df-d4d3-979c-9c96-2a02fd7fe98a@oracle.com> References: <48755CD4-2A8B-471B-865F-FACE080213A9@kungfoocoder.org> <0a11a64d-2449-0eb4-fee4-a1e24b1b944c@oracle.com> <2640b7df-d4d3-979c-9c96-2a02fd7fe98a@oracle.com> Message-ID: <330121A3-56DE-4C2E-9178-244150A71DA4@kungfoocoder.org> Hi David, Thanks for creating that issue! As to when we first saw it, we first saw this in 17.0.1, however that was also the first version that we widely deployed, prior to that we were using OpenJ9 Java 11. However, when moving to Java 17, we also moved back to hotspot as well. Cheers, Paul > On 1 Aug 2022, at 03:16, David Holmes wrote: > > https://bugs.openjdk.org/browse/JDK-8291596 > > David > > On 1/08/2022 10:58 am, David Holmes wrote: >> Hi Paul, >> Redirecting to hotspot-dev as this issue is not likely to get much visibility on jdk-updates-dev. >> Probably worth filing an issue in bugs.openjdk.org if you can. >> Cheers, >> David >> On 1/08/2022 10:37 am, Paul Wagland wrote: >>> Hi all, >>> >>> We have been running into a problem with Java 17.0.1, 17.0.2, and now 17.0.3. >>> >>> # java --version >>> openjdk 17.0.3 2022-04-19 >>> OpenJDK Runtime Environment Temurin-17.0.3+7 (build 17.0.3+7) >>> OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (build 17.0.3+7, mixed mode, sharing) >>> >>> >>> The issue that we are seeing is very similar in behaviour to https://bugs.openjdk.org/browse/JDK-8277212 , with a couple of notable exceptions: >>> 1. We are seeing this issue in 17.0.3, whereas JDK-8277212 was resolved in either 17.0.2 or 17.0.3-oracle. >>> 2. We are using G1GC, not ZGC >>> >>> Unfortunately, we don?t know how to reproduce this issue, we are seeing it happen about once a week across our fleet. We have about 300 instances of Java running various different workloads. >>> >>> What happens is that on a machine where this occurs, after a period of time we see CPU usage suddenly spike, and the gc logs suddenly start getting flooded with ICBufferFull messages, at the rate of about 430 a second. When doing thread dumps to see what is happening at that time, we find most threads end up very deep in a regex processing stack, unfortunately we have one of these fairly central to the product, so this ends up affecting most threads. It seems that almost everything that isn?t thread parsing operates at, or near to, full speed. This is one of the reasons that this feels similar to JDK-8277212, since that was mashing the VTABLES, and because of the way that regexes work, they would appear to use a lot of VTABLE lookups, so any slowdown in that area, is likely to affect them greatly. Note that this is pure supposition, and I would love to know if there is any way if we can prove, or disprove this, either via testing, or additional logging. >>> >>> Unfortunately, as mentioned above, we are not able to reproduce this in our test environments, and we are only seeing this in customer environments, and then not with any clearly identifiable cause. We have seen the issue about a dozen times, over 17.0.1, 17.0.2, and recently, 17.0.3. >>> >>> We have done some performance testing, and during the slow-down we get, for our regex processing test: >>> >>> 10 iterations of testString 1 took 10700ms (1070004460ns/match) (matched=false) >>> 10 iterations of testString 2 took 8965ms (896560879ns/match) (matched=true) >>> >>> Normal timings looks like: >>> 18503 iterations of testString 1 took 1000ms (54047ns/match) (matched=false) >>> 40954 iterations of testString 2 took 1000ms (24417ns/match) (matched=true) >>> >>> So that represents a slowdown of roughly 20,000 times! >>> >>> We have another test that is mostly map lookup heavy, and during the high CPU it has: >>> doMapOperations:2:31076ns >>> doMapOperations:3:16951ns >>> doMapOperations:4:14192ns >>> >>> While normally it has: >>> doMapOperations:2:27392ns >>> doMapOperations:3:7987ns >>> doMapOperations:4:6079ns >>> >>> So a slowdown of maybe a factor of 2, which is perfectly explainable by the very high CPU/system load. >>> >>> Our startup arguments are: >>> >>> JVM startup arguments: >>> -javaagent:/opt/jmx-exporter/jmx-exporter.jar=9404:/opt/jmx-exporter/config.yaml >>> --add-opens=java.base/java.lang=ALL-UNNAMED >>> --add-opens=java.base/java.io =ALL-UNNAMED >>> --add-opens=java.base/java.util=ALL-UNNAMED >>> --add-opens=java.base/java.util.concurrent=ALL-UNNAMED >>> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED >>> -Dnop >>> -Djava.security.egd=file:/dev/./urandom >>> -XX:+HeapDumpOnOutOfMemoryError >>> -XX:HeapDumpPath=/opt/?/logs >>> -Djava.awt.headless=true >>> -XX:+PrintFlagsFinal >>> -DRP_CONTEXTPATH= >>> -DRP_UNPACKWAR=true >>> -XX:FlightRecorderOptions=stackdepth=256 >>> -XX:+UnlockDiagnosticVMOptions >>> -XX:+DebugNonSafepoints >>> -Xlog:gc*,safepoint=info:file=/opt/?/logs/verbosegc.log:time,uptimemillis:filecount=10,filesize=50M >>> -Xlog:class*=info:file=/opt/?/logs/classload.log:time,uptimemillis,level,tags:filecount=10,filesize=50M >>> -XX:+UseG1GC >>> -XX:G1PeriodicGCInterval=10000 >>> -XX:+ParallelRefProcEnabled >>> -XX:MaxDirectMemorySize=25M >>> -XX:MaxMetaspaceSize=300M >>> -XX:MetaspaceSize=100M >>> -Xss1024K >>> -XX:ReservedCodeCacheSize=150M >>> -XX:+SegmentedCodeCache >>> -Xmx862m >>> -XX:MaxMetaspaceFreeRatio=20 >>> -XX:MinMetaspaceFreeRatio=5 >>> -XX:MaxHeapFreeRatio=40 >>> -XX:MinHeapFreeRatio=5 >>> -Djdk.nio.maxCachedBufferSize=8192 >>> -XX:SoftMaxHeapSize=646m >>> -Dlog4j2.disableJmx=true >>> -Djdk.tls.ephemeralDHKeySize=2048 >>> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources >>> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 >>> -Dignore.endorsed.dirs= >>> -Dcatalina.base=/opt/?/server1 >>> -Dcatalina.home=/opt/?/tomcat >>> -Djava.io.tmpdir=/opt/?/temp >>> >>> Can anyone think of anything that we can do to ameliorate this problem, apart from not using regexes, which we are moving towards, but I think that they are the victim here, not the cause of the problem, since in normal use, they are ?fast enough?. >>> >>> If there is any information that I can add, please let me know! >>> >>> Cheers, >>> Paul From duke at openjdk.org Mon Aug 1 06:42:58 2022 From: duke at openjdk.org (Yi-Fan Tsai) Date: Mon, 1 Aug 2022 06:42:58 GMT Subject: RFR: 8280152: AArch64: Reuse runtime call trampolines [v6] In-Reply-To: <2Rz88X0uWMdi7N4NFC36ZiMXgOhUmh0XehnaOKo6JWM=.9422ee14-4e73-47a5-a211-842fa5331391@github.com> References: <2Rz88X0uWMdi7N4NFC36ZiMXgOhUmh0XehnaOKo6JWM=.9422ee14-4e73-47a5-a211-842fa5331391@github.com> Message-ID: <8uVGzNDFHtox07l74pkh8eDLkonkt2Ug6Jz8RsRuncc=.47db2287-d368-44ec-8cc6-c992c85e2335@github.com> > A trampoline stub could be generated for each runtime call. These trampolines could be duplication if the callees are the same. This change delays the stub generation and generates one stub for a distinct callee. > > Benchmark als, chi-square, dec-tree, gauss-mix, log-regression, movie-lens, naive-bayes, page-rank, fj-means, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~4.7% reduction on average. Yi-Fan Tsai 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' of https://github.com/yftsai/jdk into JDK-8280152 - Reduce maximum hash table size and cleanup - Use ResizeableResourceHashtable - Use a hash table to deduplicate - Rename variables - Remove dead codes - Reuse runtime call trampolines ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9405/files - new: https://git.openjdk.org/jdk/pull/9405/files/baf72825..877ebb8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9405&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9405&range=04-05 Stats: 105004 lines in 2480 files changed: 55826 ins; 32033 del; 17145 mod Patch: https://git.openjdk.org/jdk/pull/9405.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9405/head:pull/9405 PR: https://git.openjdk.org/jdk/pull/9405 From tschatzl at openjdk.org Mon Aug 1 09:52:13 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Aug 2022 09:52:13 GMT Subject: RFR: 8290966: G1: Record number of PLAB filled and number of direct allocations [v2] In-Reply-To: References: Message-ID: > Hi all, > > for evaluation in [JDK-8288966](https://bugs.openjdk.org/browse/JDK-8288966) I added statistics output that show the amount of PLAB fills and direct allocations; I think this is useful for similar evaluations in the future, so I kept and split it out from that change. Adds these values to the existing JFR event too. > > Testing: PLAB related tests, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: kbarrett review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9626/files - new: https://git.openjdk.org/jdk/pull/9626/files/7b242dd1..6194eea8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9626&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9626&range=00-01 Stats: 15 lines in 1 file changed: 10 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9626.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9626/head:pull/9626 PR: https://git.openjdk.org/jdk/pull/9626 From tschatzl at openjdk.org Mon Aug 1 09:54:49 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Aug 2022 09:54:49 GMT Subject: RFR: 8290966: G1: Record number of PLAB filled and number of direct allocations [v2] In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 20:29:22 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> kbarrett review > > Looks good. Just a couple whitespace comments. Thanks @kimbarrett @sangheon for your reviews ------------- PR: https://git.openjdk.org/jdk/pull/9626 From tschatzl at openjdk.org Mon Aug 1 09:56:22 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Aug 2022 09:56:22 GMT Subject: Integrated: 8290966: G1: Record number of PLAB filled and number of direct allocations In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 14:11:24 GMT, Thomas Schatzl wrote: > Hi all, > > for evaluation in [JDK-8288966](https://bugs.openjdk.org/browse/JDK-8288966) I added statistics output that show the amount of PLAB fills and direct allocations; I think this is useful for similar evaluations in the future, so I kept and split it out from that change. Adds these values to the existing JFR event too. > > Testing: PLAB related tests, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 30205bb2 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/30205bb289e9b25d60474b24b891e15923071b5a Stats: 73 lines in 9 files changed: 51 ins; 0 del; 22 mod 8290966: G1: Record number of PLAB filled and number of direct allocations Reviewed-by: sangheki, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/9626 From duke at openjdk.org Mon Aug 1 12:15:46 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Mon, 1 Aug 2022 12:15:46 GMT Subject: RFR: 8287393: AArch64: Remove trampoline_call1 [v2] In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 09:53:45 GMT, Evgeny Astigeevich wrote: >> This is all rather complicated and obscure. It seems to me that passing a bool `check_emit_size` is exactly what we should do: it's more explicit and helps the reader. > > I've restored `check_emit_size` and created an assert to guard it is properly used. > I'll remove `cbuf` by fixing: https://bugs.openjdk.org/browse/JDK-8287394 Hi Andrew, Any comments on the latest version? ------------- PR: https://git.openjdk.org/jdk/pull/9592 From sspitsyn at openjdk.org Mon Aug 1 12:55:58 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 1 Aug 2022 12:55:58 GMT Subject: RFR: 8290908: misc tests fail: assert(!thread->owns_locks()) failed: must release all locks when leaving VM Message-ID: This is a regression that has been introduced by the fix of: [8256811](https://bugs.openjdk.org/browse/JDK-8256811): Delayed/missed jdwp class unloading events This is the relevant comment from Zhengyu: It is caused by https://bugs.openjdk.org/browse/JDK-8256811 as JvmtiExport::post_object_free() call does not expect under any lock. I think we can move following code outside of lock, as flush_obect_free_events() races ServiceThread's JvmtiTagMap::flush_all_object_free_events() call anyway. if (event_type == JVMTI_EVENT_OBJECT_FREE) { flush_object_free_events(env); } The fix is as was suggested by Zhengyu above. I was not able to reproduce JCK and nsk.jvmti test failures mentioned in the bug report. However, this fix should address the problem as it moves the call to `flush_object_free_events(env)` out of a critical section with a lock. ------------- Commit messages: - 8290908: misc tests fail: assert(->owns_locks()) failed: must release all locks when leaving VM Changes: https://git.openjdk.org/jdk/pull/9699/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9699&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290908 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9699.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9699/head:pull/9699 PR: https://git.openjdk.org/jdk/pull/9699 From pli at openjdk.org Mon Aug 1 12:56:36 2022 From: pli at openjdk.org (Pengfei Li) Date: Mon, 1 Aug 2022 12:56:36 GMT Subject: RFR: 8291597: [BACKOUT] JDK-8289996: Fix array range check hoisting for some scaled loop iv Message-ID: This reverts JDK-8289996 as multiple jtreg fails after that change. ------------- Commit messages: - 8291597: [BACKOUT] JDK-8289996: Fix array range check hoisting for some scaled loop iv Changes: https://git.openjdk.org/jdk/pull/9696/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9696&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291597 Stats: 193 lines in 4 files changed: 2 ins; 186 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9696.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9696/head:pull/9696 PR: https://git.openjdk.org/jdk/pull/9696 From hseigel at openjdk.org Mon Aug 1 13:33:00 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 1 Aug 2022 13:33:00 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: <9bk3CPQqVLEwoDzrdWzA7dF9682yMOSwZb-5xlVMfd4=.1c4e7037-ddd0-446f-b424-6d2634be41f4@github.com> On Sun, 31 Jul 2022 22:05:15 GMT, David Holmes wrote: >> Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. >> >> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. >> >> Thanks, Harold > > src/hotspot/share/prims/jvm.cpp line 4064: > >> 4062: assert(c->is_instance_klass(), "must be"); >> 4063: InstanceKlass* ik = InstanceKlass::cast(c); >> 4064: return (ik->minor_version() << 16) | ik->major_version(); > > I'm curious why the format is minor:major rather than major:minor ? This was requested by @RogerRiggs Major high vs low bits requires either: High bits: val >>>16 Low bits: val & 0xffff Except for preview, the minor version is 0, so putting major version in the low bits allows trivial comparison (without masking); but may lead to bugs due to carelessness. > src/java.base/share/classes/java/lang/Class.java line 4698: > >> 4696: * >> 4697: * If the class is an array type then the access flags of the component type is >> 4698: * returned. If the class is a primitive then ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC. > > The `ACC_ABSTRACT` seems odd - is that way of indicating this "class" can't be instantiated? Is there some spec document that explains this choice? I don't know why API's such as JVM_GetClassModifiers() and JVM_GetClassAccessFlags return ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC for primitives. Nor could I find a spec that discussed access flags for primitives. But, I didn't want to change what's been returned for primitives in existing code. > test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 31: > >> 29: * @modules java.base/java.lang:open >> 30: * @compile classFileVersions.jcod >> 31: * @run main/othervm --enable-preview ClassFileVersionTest > > What preview feature is being used here? No preview feature is being used but --enable-preview is needed here for the JVM to accept a class with a minor version of 65535. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From rriggs at openjdk.org Mon Aug 1 14:08:08 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 1 Aug 2022 14:08:08 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Sat, 30 Jul 2022 07:45:31 GMT, David Holmes wrote: >> It is usual for the Java code to do such checks and throw exceptions, so that the VM assumes it is correct and only asserts incase something has been missed on the Java side. > > Though in this case the Java code has defined behaviour for array types so it is correct for the VM to assume this is not an array type and to assert if it is. My companion question was whether the native code can for efficiently map from array class to component type than Java. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From aph at openjdk.org Mon Aug 1 14:19:52 2022 From: aph at openjdk.org (Andrew Haley) Date: Mon, 1 Aug 2022 14:19:52 GMT Subject: RFR: 8287393: AArch64: Remove trampoline_call1 [v3] In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 09:53:38 GMT, Evgeny Astigeevich wrote: >> `trampoline_call` can do dummy code generation to calculate the size of C2 generated code. This is done in the output phase. In [src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L1042](https://github.com/openjdk/jdk/blob/e0d361cea91d3dd1450aece73f660b4abb7ce5fa/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L1042) Loom code needed to generate a trampoline call outside of C2 and without the output phase. This caused test crashes. The project Loom added `trampoline_call1` to workaround the crashes. >> >> This PR improves detection of C2 output phase which makes `trampoline_call1` redundant. >> >> Tested the fastdebug/release builds: >> - `'gtest`: Passed >> - `tier1`...`tier2`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Restore check_emit_size parameter Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9592 From duke at openjdk.org Mon Aug 1 14:35:06 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Mon, 1 Aug 2022 14:35:06 GMT Subject: RFR: 8287393: AArch64: Remove trampoline_call1 [v3] In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 09:53:38 GMT, Evgeny Astigeevich wrote: >> `trampoline_call` can do dummy code generation to calculate the size of C2 generated code. This is done in the output phase. In [src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L1042](https://github.com/openjdk/jdk/blob/e0d361cea91d3dd1450aece73f660b4abb7ce5fa/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L1042) Loom code needed to generate a trampoline call outside of C2 and without the output phase. This caused test crashes. The project Loom added `trampoline_call1` to workaround the crashes. >> >> This PR improves detection of C2 output phase which makes `trampoline_call1` redundant. >> >> Tested the fastdebug/release builds: >> - `'gtest`: Passed >> - `tier1`...`tier2`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Restore check_emit_size parameter Andrew, thank you for the review. ------------- PR: https://git.openjdk.org/jdk/pull/9592 From hseigel at openjdk.org Mon Aug 1 15:17:56 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 1 Aug 2022 15:17:56 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Sun, 31 Jul 2022 22:22:24 GMT, David Holmes wrote: >> Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. >> >> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. >> >> Thanks, Harold > > test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 55: > >> 53: >> 54: testIt("Version64", 64); >> 55: testIt("Version59", 59); > > Any particular reason to choose 59? Shouldn't there also be tests for non-zero minor versions? No particular reason for choosing 59 other than it's different and less than 64. Test case Version64_65535 has a non-zero minor version. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From gziemski at openjdk.org Mon Aug 1 16:07:16 2022 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 1 Aug 2022 16:07:16 GMT Subject: RFR: 8290840: Refactor the "os" class [v2] In-Reply-To: References: <8vUXDokoOuVschkyCtu5BNpv8ZYIv01RllzKWhdZdXQ=.aa253ce1-7e3b-4efc-9b90-930a2a9b3ea5@github.com> <29bp6K9fT5FB6NuMaSRg9bKIp66HaXG_iza8hPSTENE=.c9487746-812c-45c3-aa01-0baa5ebb4483@github.com> Message-ID: On Fri, 29 Jul 2022 20:25:52 GMT, Ioi Lam wrote: >> src/hotspot/share/runtime/os.inline.hpp line 60: >> >>> 58: inline void* os::resolve_function_descriptor(void* p) { >>> 59: return NULL; >>> 60: } >> >> This is unnecessary and could be removed if we did: >> >> >> +#ifdef HAVE_FUNCTION_DESCRIPTORS >> // Used only on PPC. >> inline static void* resolve_function_descriptor(void* p); >> +#endif >> >> >> in `os.hpp` > > After this PR, os.hpp no longer includes any os- or cpu-specific os_xxx.hpp files. I did this to avoid including large amount of os-specific declarations (such as os::Linux, which is about 400 lines) into generic source files, which aren't interested in these declarations. > > As a result of this change, there's no way to let os.hpp know whether `HAVE_FUNCTION_DESCRIPTORS` is defined for the current OS+CPU. If we want to do that, we need to either: > > - include os_xxx.hpp back in os.hpp (which I want to avoid) > - add new header files such as `os_.defs.hpp` `os__.defs.hpp` to define `HAVE_FUNCTION_DESCRIPTORS` (this will result in lots of header files that usually have nothing inside) > > Since there are only 4 functions that fall under this pattern (functions that are used in generic code but most platforms have dummy implementations), I think what I have is a good compromise Could we do: #if defined(LINUX) && defined(PPC) && !defined(ABI_ELFv2) #define HAVE_FUNCTION_DESCRIPTORS #endif in `os.hpp` and whatever the equivalent for AIX/PPC is? ------------- PR: https://git.openjdk.org/jdk/pull/9600 From hseigel at openjdk.org Mon Aug 1 16:40:54 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 1 Aug 2022 16:40:54 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 21:21:43 GMT, Roger Riggs wrote: >> Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. >> >> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. >> >> Thanks, Harold > > test/hotspot/jtreg/runtime/ClassFile/classAccessFlagsRaw.jcod line 25: > >> 23: */ >> 24: >> 25: // Class with ACC_SUPER set > > Can these classes be defined more succinctly either in Java or .asm? The jcod test files are relatively small so I don' think they need to be rewritten using asm. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From hseigel at openjdk.org Mon Aug 1 16:47:51 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 1 Aug 2022 16:47:51 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 14:04:22 GMT, Roger Riggs wrote: >> Though in this case the Java code has defined behaviour for array types so it is correct for the VM to assume this is not an array type and to assert if it is. > > My companion question was whether the native code can for efficiently map from array class to component type than Java. I don't know whether Java or the JVM is faster but I would rather keep this code in Java so that I don't have to change existing method JVM_GetClassAccessFlags(). (It's used by Class.getClassAccessFlagsRaw().) ------------- PR: https://git.openjdk.org/jdk/pull/9688 From shade at openjdk.org Mon Aug 1 17:09:44 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 1 Aug 2022 17:09:44 GMT Subject: RFR: 8291633: Build failures with GCC 11, Alpine 3 due to incompatible casts from nullptr Message-ID: Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. They fall into three categories: - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does; - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it; - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead. Additional testing: - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15 - [ ] Linux x86_64 fastdebug tier1 with GCC 9.3.0 ------------- Commit messages: - More work - Fix Changes: https://git.openjdk.org/jdk/pull/9705/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9705&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291633 Stats: 15 lines in 6 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/9705.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9705/head:pull/9705 PR: https://git.openjdk.org/jdk/pull/9705 From rriggs at openjdk.org Mon Aug 1 17:10:22 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 1 Aug 2022 17:10:22 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 16:44:22 GMT, Harold Seigel wrote: >> My companion question was whether the native code can for efficiently map from array class to component type than Java. > > I don't know whether Java or the JVM is faster but I would rather keep this code in Java so that I don't have to change existing method JVM_GetClassAccessFlags(). (It's used by Class.getClassAccessFlagsRaw().) Makes sense, re-using the existing method. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From rriggs at openjdk.org Mon Aug 1 17:10:24 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 1 Aug 2022 17:10:24 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 16:38:48 GMT, Harold Seigel wrote: >> test/hotspot/jtreg/runtime/ClassFile/classAccessFlagsRaw.jcod line 25: >> >>> 23: */ >>> 24: >>> 25: // Class with ACC_SUPER set >> >> Can these classes be defined more succinctly either in Java or .asm? > > The jcod test files are relatively small so I don' think they need to be rewritten using asm. ok, It mostly knowing which few of the lines are relevant to the test vs. just boilerplate to make a complete class. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From hseigel at openjdk.org Mon Aug 1 18:51:10 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 1 Aug 2022 18:51:10 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v2] In-Reply-To: References: Message-ID: > Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. > > The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9688/files - new: https://git.openjdk.org/jdk/pull/9688/files/2f5d1468..82890e56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9688&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9688&range=00-01 Stats: 55 lines in 5 files changed: 27 ins; 10 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/9688.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9688/head:pull/9688 PR: https://git.openjdk.org/jdk/pull/9688 From cjplummer at openjdk.org Mon Aug 1 18:54:16 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 1 Aug 2022 18:54:16 GMT Subject: RFR: 8290908: misc tests fail: assert(!thread->owns_locks()) failed: must release all locks when leaving VM In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 07:41:50 GMT, Serguei Spitsyn wrote: > This is a regression that has been introduced by the fix of: > [8256811](https://bugs.openjdk.org/browse/JDK-8256811): Delayed/missed jdwp class unloading events > > This is the relevant comment from Zhengyu: > > It is caused by https://bugs.openjdk.org/browse/JDK-8256811 as JvmtiExport::post_object_free() call does not expect under any lock. > > I think we can move following code outside of lock, as flush_obect_free_events() races ServiceThread's JvmtiTagMap::flush_all_object_free_events() call anyway. > > if (event_type == JVMTI_EVENT_OBJECT_FREE) { > flush_object_free_events(env); > } > > The fix is as was suggested by Zhengyu above. > I was not able to reproduce JCK and nsk.jvmti test failures mentioned in the bug report. > However, this fix should address the problem as it moves the call to `flush_object_free_events(env)` out of a critical section with a lock. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9699 From hseigel at openjdk.org Mon Aug 1 18:57:19 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 1 Aug 2022 18:57:19 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v2] In-Reply-To: References: Message-ID: <-qL5Q9n31S1en7zXqUUHSepr8rNcX22XEXHgC9Xb3X0=.3e7b0376-3b83-4bf7-9051-53d709f698c9@github.com> On Mon, 1 Aug 2022 18:51:10 GMT, Harold Seigel wrote: >> Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. >> >> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's Thanks Brian, Roger, and David for looking at this. I pushed a new commit to address the review comments, add mulit-dimensional array test cases, and simplify new java.lang.Class API's. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From hseigel at openjdk.org Mon Aug 1 18:57:21 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 1 Aug 2022 18:57:21 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v2] In-Reply-To: References: Message-ID: On Sun, 31 Jul 2022 22:02:11 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's > > src/hotspot/share/include/jvm.h line 1163: > >> 1161: >> 1162: /* >> 1163: * Value types support. > > Value types? This is supporting the core reflection work isn't it? I fixed this in the second commit. > src/hotspot/share/prims/jvm.cpp line 4050: > >> 4048: /* >> 4049: * Return the current class's class file version. The low order 16 bits of the >> 4050: * the returned jint contains the class's major version. The high order 16 bits > > typo "the the" across the lines > typo s/contains/contain/ Fixed! > src/hotspot/share/prims/jvm.cpp line 4051: > >> 4049: * Return the current class's class file version. The low order 16 bits of the >> 4050: * the returned jint contains the class's major version. The high order 16 bits >> 4051: * contains the class's minor version. > > typo s/contains/contain/ Fixed. > test/hotspot/jtreg/runtime/ClassFile/ClassAccessFlagsRawTest.java line 66: > >> 64: flags = (int)m.invoke((new SUPERnotset[2]).getClass()); >> 65: if (flags != 1) { >> 66: throw new RuntimeException("expected 1, got " + flags + " for object array"); > > Again hex output would be clearer Changed this in the second commit to display hex outout. > test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 45: > >> 43: if (ver != expectedResult) { >> 44: throw new RuntimeException( >> 45: "expected " + expectedResult + ", got " + ver + " for class " + className); > > It would be clearer to show the expected and actual in minor:major format. That way if the test fails we can easily see which bit is wrong. Changed to display as major:minor version. > test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 62: > >> 60: int ver = (int)m.invoke((new int[3]).getClass()); >> 61: if (ver != 64) { >> 62: throw new RuntimeException("expected 64, got " + ver + " for primitive array"); > > Again minor:major format. Changed to display as major:minor version. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From hseigel at openjdk.org Mon Aug 1 18:57:22 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 1 Aug 2022 18:57:22 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v2] In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 21:08:43 GMT, Roger Riggs wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's > > test/hotspot/jtreg/runtime/ClassFile/ClassAccessFlagsRawTest.java line 59: > >> 57: // test primitive array. should return ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC. >> 58: int flags = (int)m.invoke((new int[3]).getClass()); >> 59: if (flags != 1041) { > > Can this be a hex constant, It's easier to understand the bits. > Or assemble the flags from java.lang.reflect.Modifier.XXX static fields. I changed this in the second commit to use java.lang.reflect.Modifier static fields. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From stuefe at openjdk.org Mon Aug 1 19:32:10 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 1 Aug 2022 19:32:10 GMT Subject: RFR: 8290840: Refactor the "os" class [v3] In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 20:31:42 GMT, Ioi Lam wrote: >> Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. >> >> The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. >> >> This RFE tries to address the following: >> >> - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. >> - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo Very good work. Only small remarks/nitpickings. One question though, how does it work if I want to use an API implemented on a per-platform base in shared code? E.g. `zero_page_read_protected()`? I include `os.hpp` to get the definition, but how do I get the implementation? I have to include the platform-specific inline header too? Still with the OS_HEADER macro? Cheers, Thomas src/hotspot/os/aix/os_aix.hpp line 180: > 178: static bool get_meminfo(meminfo_t* pmi); > 179: > 180: // PPC only Since your are here, remove comment? There has not been an AIX on something other than power for ~25 years. src/hotspot/os/aix/os_aix.inline.hpp line 37: > 35: inline bool os::zero_page_read_protected() { > 36: return false; > 37: } I have the feeling many of these functions are really just global constants and that the coding could be simplified further in followup RFEs. src/hotspot/os/linux/os_linux.cpp line 4492: > 4490: // perform the workaround > 4491: Linux::capture_initial_stack(JavaThread::stack_size_at_create()); > 4492: Linux::workaround_expand_exec_shield_cs_limit(); You could move `workaround_expand_exec_shield_cs_limit()` into this file, declare it static, and remove all mentionings from headers. It now lives in os_linux_x86.cpp, but since it has to be wrapped with !zero !64bit already it is an odd misfit anyway. So its not much more "wrong" for it to live here. src/hotspot/share/runtime/os.hpp line 92: > 90: // The Porting APIs declared as "inline" in os.hpp must be > 91: // implemented in one of the two .inline.hpp files, depending on whether > 92: // the feature is generic to the OS, or specific to a particular CPU generic? Did you mean specific? E.g. "depending on whether the feature is specific to a certain OS or an OS+CPU combination" ? src/hotspot/share/runtime/os.inline.hpp line 37: > 35: // Provide default empty implementation. > 36: > 37: #ifndef PLATFORM_PRINT_NATIVE_STACK Could you rename this to HAVE_PLATFORM_PRINT_NATIVE_STACK? ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/9600 From stuefe at openjdk.org Mon Aug 1 19:32:13 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 1 Aug 2022 19:32:13 GMT Subject: RFR: 8290840: Refactor the "os" class [v2] In-Reply-To: References: <8vUXDokoOuVschkyCtu5BNpv8ZYIv01RllzKWhdZdXQ=.aa253ce1-7e3b-4efc-9b90-930a2a9b3ea5@github.com> <29bp6K9fT5FB6NuMaSRg9bKIp66HaXG_iza8hPSTENE=.c9487746-812c-45c3-aa01-0baa5ebb4483@github.com> Message-ID: On Mon, 1 Aug 2022 16:04:25 GMT, Gerard Ziemski wrote: >> After this PR, os.hpp no longer includes any os- or cpu-specific os_xxx.hpp files. I did this to avoid including large amount of os-specific declarations (such as os::Linux, which is about 400 lines) into generic source files, which aren't interested in these declarations. >> >> As a result of this change, there's no way to let os.hpp know whether `HAVE_FUNCTION_DESCRIPTORS` is defined for the current OS+CPU. If we want to do that, we need to either: >> >> - include os_xxx.hpp back in os.hpp (which I want to avoid) >> - add new header files such as `os_.defs.hpp` `os__.defs.hpp` to define `HAVE_FUNCTION_DESCRIPTORS` (this will result in lots of header files that usually have nothing inside) >> >> Since there are only 4 functions that fall under this pattern (functions that are used in generic code but most platforms have dummy implementations), I think what I have is a good compromise > > Could we do: > > > #if defined(LINUX) && defined(PPC) && !defined(ABI_ELFv2) > #define HAVE_FUNCTION_DESCRIPTORS > #endif > > > in `os.hpp` and whatever the equivalent for AIX/PPC is? #if defined(PPC) && !defined(ABI_ELFv2) #define HAVE_FUNCTION_DESCRIPTORS #endif should do the trick. AIX uses XCOFF, not Elf, so ABI_ELFv2 should never be defined. But I have no emotions. We can leave it like this. Or do it in a follow up. ------------- PR: https://git.openjdk.org/jdk/pull/9600 From stuefe at openjdk.org Mon Aug 1 19:35:25 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 1 Aug 2022 19:35:25 GMT Subject: RFR: 8291633: Build failures with GCC 11, Alpine 3 due to incompatible casts from nullptr In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 17:01:51 GMT, Aleksey Shipilev wrote: > Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. > > They fall into three categories: > - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does; > - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it; > - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead. > > Additional testing: > - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15, GCC 11.2.1 > - [ ] Linux x86_64 fastdebug tier1 with GCC 9.3.0 LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/9705 From phh at openjdk.org Mon Aug 1 19:46:17 2022 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 1 Aug 2022 19:46:17 GMT Subject: RFR: 8287393: AArch64: Remove trampoline_call1 [v3] In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 09:53:38 GMT, Evgeny Astigeevich wrote: >> `trampoline_call` can do dummy code generation to calculate the size of C2 generated code. This is done in the output phase. In [src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L1042](https://github.com/openjdk/jdk/blob/e0d361cea91d3dd1450aece73f660b4abb7ce5fa/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L1042) Loom code needed to generate a trampoline call outside of C2 and without the output phase. This caused test crashes. The project Loom added `trampoline_call1` to workaround the crashes. >> >> This PR improves detection of C2 output phase which makes `trampoline_call1` redundant. >> >> Tested the fastdebug/release builds: >> - `'gtest`: Passed >> - `tier1`...`tier2`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Restore check_emit_size parameter Marked as reviewed by phh (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9592 From duke at openjdk.org Mon Aug 1 19:56:06 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Mon, 1 Aug 2022 19:56:06 GMT Subject: Integrated: 8287393: AArch64: Remove trampoline_call1 In-Reply-To: References: Message-ID: <8s1Vgn9klz-wTgy3ZdbXumXBzu1UHYQATKcQpfAXYSM=.2d59aa24-4163-4950-9b8d-213bb8d54f50@github.com> On Thu, 21 Jul 2022 14:00:48 GMT, Evgeny Astigeevich wrote: > `trampoline_call` can do dummy code generation to calculate the size of C2 generated code. This is done in the output phase. In [src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L1042](https://github.com/openjdk/jdk/blob/e0d361cea91d3dd1450aece73f660b4abb7ce5fa/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L1042) Loom code needed to generate a trampoline call outside of C2 and without the output phase. This caused test crashes. The project Loom added `trampoline_call1` to workaround the crashes. > > This PR improves detection of C2 output phase which makes `trampoline_call1` redundant. > > Tested the fastdebug/release builds: > - `'gtest`: Passed > - `tier1`...`tier2`: Passed This pull request has now been integrated. Changeset: 6cbc234a Author: Evgeny Astigeevich Committer: Paul Hohensee URL: https://git.openjdk.org/jdk/commit/6cbc234ad17c5a0c4b3d6ea76f807c27c1dc8330 Stats: 11 lines in 3 files changed: 4 ins; 2 del; 5 mod 8287393: AArch64: Remove trampoline_call1 Reviewed-by: aph, phh ------------- PR: https://git.openjdk.org/jdk/pull/9592 From iklam at openjdk.org Mon Aug 1 20:33:05 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 1 Aug 2022 20:33:05 GMT Subject: RFR: 8290718: Remove ALLOCATION_SUPER_CLASS_SPEC In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 12:50:04 GMT, Coleen Phillimore wrote: > This super class simply exists to have virtual functions for print() in non-product mode. In CHeapObj objects, it creates a vptr that break deterministic archive creation when I change the type of ModuleEntry in upcoming work. > I moved the virtual print functions to ResourceObj and CompilationResourceObj since there are still several print functions called for those types. Many were for the compilation types. Maybe someone should fix those someday. > Tested with tier1 on Oracle supported platforms and builds-only for others (ppc, s390, etc). LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/9591 From coleenp at openjdk.org Mon Aug 1 20:54:24 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Aug 2022 20:54:24 GMT Subject: RFR: 8290812: Add a test for ResourceHashtable [v4] In-Reply-To: References: Message-ID: > I added a test for ResourceHashtable to show the interactions with it and Symbol* refcounting. > Tested with tier1 on Oracle platforms. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix self assignment I hope. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9603/files - new: https://git.openjdk.org/jdk/pull/9603/files/64f3338e..caf3ba18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9603&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9603&range=02-03 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9603.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9603/head:pull/9603 PR: https://git.openjdk.org/jdk/pull/9603 From coleenp at openjdk.org Mon Aug 1 21:20:52 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Aug 2022 21:20:52 GMT Subject: RFR: 8290812: Add a test for ResourceHashtable [v5] In-Reply-To: References: Message-ID: <8FAGC27QulbhGnrkRQKxmiRvrqSFyMWE1GycDQs65xo=.1bc3a710-7e18-4c1e-a892-8a9862bc092c@github.com> > I added a test for ResourceHashtable to show the interactions with it and Symbol* refcounting. > Tested with tier1 on Oracle platforms. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Use swap and copy value parameter trick for assignment operator. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9603/files - new: https://git.openjdk.org/jdk/pull/9603/files/caf3ba18..b3953376 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9603&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9603&range=03-04 Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9603.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9603/head:pull/9603 PR: https://git.openjdk.org/jdk/pull/9603 From dholmes at openjdk.org Mon Aug 1 21:22:13 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 1 Aug 2022 21:22:13 GMT Subject: RFR: 8287393: AArch64: Remove trampoline_call1 [v3] In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 09:53:38 GMT, Evgeny Astigeevich wrote: >> `trampoline_call` can do dummy code generation to calculate the size of C2 generated code. This is done in the output phase. In [src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L1042](https://github.com/openjdk/jdk/blob/e0d361cea91d3dd1450aece73f660b4abb7ce5fa/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L1042) Loom code needed to generate a trampoline call outside of C2 and without the output phase. This caused test crashes. The project Loom added `trampoline_call1` to workaround the crashes. >> >> This PR improves detection of C2 output phase which makes `trampoline_call1` redundant. >> >> Tested the fastdebug/release builds: >> - `'gtest`: Passed >> - `tier1`...`tier2`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Restore check_emit_size parameter This is crashing our CI builds! `# assert(StubRoutines::aarch64::complete() && Thread::current()->is_Compiler_thread() && Compile::current()->output() != __null) failed: not in output phase of C2 compilation` This change will need to be backed out. ------------- PR: https://git.openjdk.org/jdk/pull/9592 From coleenp at openjdk.org Mon Aug 1 21:30:23 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Aug 2022 21:30:23 GMT Subject: RFR: 8290718: Remove ALLOCATION_SUPER_CLASS_SPEC In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 12:50:04 GMT, Coleen Phillimore wrote: > This super class simply exists to have virtual functions for print() in non-product mode. In CHeapObj objects, it creates a vptr that break deterministic archive creation when I change the type of ModuleEntry in upcoming work. > I moved the virtual print functions to ResourceObj and CompilationResourceObj since there are still several print functions called for those types. Many were for the compilation types. Maybe someone should fix those someday. > Tested with tier1 on Oracle supported platforms and builds-only for others (ppc, s390, etc). Thanks Ioi! ------------- PR: https://git.openjdk.org/jdk/pull/9591 From coleenp at openjdk.org Mon Aug 1 21:30:23 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Aug 2022 21:30:23 GMT Subject: Integrated: 8290718: Remove ALLOCATION_SUPER_CLASS_SPEC In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 12:50:04 GMT, Coleen Phillimore wrote: > This super class simply exists to have virtual functions for print() in non-product mode. In CHeapObj objects, it creates a vptr that break deterministic archive creation when I change the type of ModuleEntry in upcoming work. > I moved the virtual print functions to ResourceObj and CompilationResourceObj since there are still several print functions called for those types. Many were for the compilation types. Maybe someone should fix those someday. > Tested with tier1 on Oracle supported platforms and builds-only for others (ppc, s390, etc). This pull request has now been integrated. Changeset: f714ac52 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/f714ac52bfe95b5a94e3994656438ef2aeab2c86 Stats: 51 lines in 6 files changed: 18 ins; 23 del; 10 mod 8290718: Remove ALLOCATION_SUPER_CLASS_SPEC Reviewed-by: zgu, iklam ------------- PR: https://git.openjdk.org/jdk/pull/9591 From coleenp at openjdk.org Mon Aug 1 21:31:12 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Aug 2022 21:31:12 GMT Subject: RFR: 8290812: Add a test for ResourceHashtable [v6] In-Reply-To: References: Message-ID: > I added a test for ResourceHashtable to show the interactions with it and Symbol* refcounting. > Tested with tier1 on Oracle platforms. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Make Symbol have a less likely CDS-shared name (with PERM refcount) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9603/files - new: https://git.openjdk.org/jdk/pull/9603/files/b3953376..87c5c05d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9603&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9603&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9603.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9603/head:pull/9603 PR: https://git.openjdk.org/jdk/pull/9603 From duke at openjdk.org Mon Aug 1 21:33:02 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Mon, 1 Aug 2022 21:33:02 GMT Subject: RFR: 8287393: AArch64: Remove trampoline_call1 [v3] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 21:18:50 GMT, David Holmes wrote: > This is crashing our CI builds! > > `# assert(StubRoutines::aarch64::complete() && Thread::current()->is_Compiler_thread() && Compile::current()->output() != __null) failed: not in output phase of C2 compilation` > > This change will need to be backed out. Hi David, Do you have a stack trace? ------------- PR: https://git.openjdk.org/jdk/pull/9592 From duke at openjdk.org Mon Aug 1 22:01:47 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Mon, 1 Aug 2022 22:01:47 GMT Subject: RFR: 8287393: AArch64: Remove trampoline_call1 [v3] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 21:18:50 GMT, David Holmes wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore check_emit_size parameter > > This is crashing our CI builds! > > `# assert(StubRoutines::aarch64::complete() && Thread::current()->is_Compiler_thread() && Compile::current()->output() != __null) failed: not in output phase of C2 compilation` > > This change will need to be backed out. @dholmes-ora, I created https://bugs.openjdk.org/browse/JDK-8291654 ------------- PR: https://git.openjdk.org/jdk/pull/9592 From duke at openjdk.org Mon Aug 1 22:17:12 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Mon, 1 Aug 2022 22:17:12 GMT Subject: RFR: 8287393: AArch64: Remove trampoline_call1 [v3] In-Reply-To: References: Message-ID: <3iD_GS_qG-q_6hw1uBWOWOFFVGxZciocIR77bJsACcA=.bbe68a03-58f9-43cf-956f-6864b8bb651a@github.com> On Mon, 1 Aug 2022 21:18:50 GMT, David Holmes wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore check_emit_size parameter > > This is crashing our CI builds! > > `# assert(StubRoutines::aarch64::complete() && Thread::current()->is_Compiler_thread() && Compile::current()->output() != __null) failed: not in output phase of C2 compilation` > > This change will need to be backed out. @dholmes-ora Fix removing the assert: https://github.com/openjdk/jdk/pull/9709 ------------- PR: https://git.openjdk.org/jdk/pull/9592 From coleenp at openjdk.org Mon Aug 1 22:17:30 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Aug 2022 22:17:30 GMT Subject: RFR: 8290812: Add a test for ResourceHashtable [v7] In-Reply-To: References: Message-ID: > I added a test for ResourceHashtable to show the interactions with it and Symbol* refcounting. > Tested with tier1 on Oracle platforms. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Expand to 5 tests and one that's simple. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9603/files - new: https://git.openjdk.org/jdk/pull/9603/files/87c5c05d..9225844f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9603&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9603&range=05-06 Stats: 44 lines in 1 file changed: 43 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9603.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9603/head:pull/9603 PR: https://git.openjdk.org/jdk/pull/9603 From duke at openjdk.org Mon Aug 1 22:22:29 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Mon, 1 Aug 2022 22:22:29 GMT Subject: RFR: 8291654: AArch64: assert from JDK-8287393 causes crashes Message-ID: https://github.com/openjdk/jdk/commit/6cbc234ad17c5a0c4b3d6ea76f807c27c1dc8330 adds an assert checking `in_scratch_emit_size` is set during the output phase of C2 compilation. The assert can fail if C1 uses `trampoline_call`. The assert is not needed as the calculation of `in_scratch_emit_size` is short-circuited to false if it is C1. ------------- Commit messages: - 8291654: AArch64: assert from JDK-8287393 causes crashes Changes: https://git.openjdk.org/jdk/pull/9709/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9709&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291654 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9709.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9709/head:pull/9709 PR: https://git.openjdk.org/jdk/pull/9709 From dholmes at openjdk.org Mon Aug 1 22:26:54 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 1 Aug 2022 22:26:54 GMT Subject: RFR: 8291654: AArch64: assert from JDK-8287393 causes crashes In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 22:13:53 GMT, Evgeny Astigeevich wrote: > https://github.com/openjdk/jdk/commit/6cbc234ad17c5a0c4b3d6ea76f807c27c1dc8330 adds an assert checking `in_scratch_emit_size` is set during the output phase of C2 compilation. The assert can fail if C1 uses `trampoline_call`. > The assert is not needed as the calculation of `in_scratch_emit_size` is short-circuited to false if it is C1. Thanks for the quick fix for this one. Sorry for lack of detail but I'm out sick at the moment. I can approve this as a trivial fix as it certainly cannot do any harm to remove the assertion and fix our CI. But it would be good if the reviewers of 8287393 chimed in at some point to confirm ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9709 From duke at openjdk.org Mon Aug 1 22:59:56 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Mon, 1 Aug 2022 22:59:56 GMT Subject: RFR: 8291654: AArch64: assert from JDK-8287393 causes crashes In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 22:23:19 GMT, David Holmes wrote: > I can approve this as a trivial fix as it certainly cannot do any harm to remove the assertion and fix our CI. But it would be good if the reviewers of 8287393 chimed in at some point to confirm It looks like the assert has UB in case of C1: static Compile* current() { return (Compile*) ciEnv::current()->compiler_data(); } In case of C1 `ciEnv::current()->compiler_data()` returns C1 `Compilation` and the cast to C2 `Compile` is invalid. ------------- PR: https://git.openjdk.org/jdk/pull/9709 From xliu at openjdk.org Mon Aug 1 23:28:32 2022 From: xliu at openjdk.org (Xin Liu) Date: Mon, 1 Aug 2022 23:28:32 GMT Subject: RFR: 8291654: AArch64: assert from JDK-8287393 causes crashes In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 22:13:53 GMT, Evgeny Astigeevich wrote: > https://github.com/openjdk/jdk/commit/6cbc234ad17c5a0c4b3d6ea76f807c27c1dc8330 adds an assert checking `in_scratch_emit_size` is set during the output phase of C2 compilation. The assert can fail if C1 uses `trampoline_call`. > The assert is not needed as the calculation of `in_scratch_emit_size` is short-circuited to false if it is C1. make sense. LGTM. I am not a reviewer. It looks like that Compile::current() is c2-specific. It doesn't return Compile* when the task is compiled by c1. ------------- Marked as reviewed by xliu (Committer). PR: https://git.openjdk.org/jdk/pull/9709 From kvn at openjdk.org Mon Aug 1 23:29:10 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 1 Aug 2022 23:29:10 GMT Subject: RFR: 8291597: [BACKOUT] JDK-8289996: Fix array range check hoisting for some scaled loop iv In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:09:43 GMT, Pengfei Li wrote: > This reverts JDK-8289996 as multiple jtreg fails after that change. Good. I submitted testing. I also verified that test cases from [8291466](https://bugs.openjdk.org/browse/JDK-8291466) and [8291510](https://bugs.openjdk.org/browse/JDK-8291510) passed with this backout. ------------- PR: https://git.openjdk.org/jdk/pull/9696 From kvn at openjdk.org Mon Aug 1 23:56:58 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 1 Aug 2022 23:56:58 GMT Subject: RFR: 8291654: AArch64: assert from JDK-8287393 causes crashes In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 22:13:53 GMT, Evgeny Astigeevich wrote: > https://github.com/openjdk/jdk/commit/6cbc234ad17c5a0c4b3d6ea76f807c27c1dc8330 adds an assert checking `in_scratch_emit_size` is set during the output phase of C2 compilation. The assert can fail if C1 uses `trampoline_call`. > The assert is not needed as the calculation of `in_scratch_emit_size` is short-circuited to false if it is C1. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 883: > 881: assert(StubRoutines::aarch64::complete() && > 882: Thread::current()->is_Compiler_thread() && > 883: Compile::current()->output() != NULL, "not in output phase of C2 compilation"); The code is under `#ifdef COMPILER2` which assumes that it is executed only for C2. Which make it confusing because it CAN be executed by C1. There is check at line 885 `is_c2_compile()` which is true only for C2. May be we can rearrange code to make it less confusing. On other hand if `check_emit_size` could be `true` for C1 why we should emit trampoline for it and not for C2? ------------- PR: https://git.openjdk.org/jdk/pull/9709 From kvn at openjdk.org Tue Aug 2 00:32:31 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 2 Aug 2022 00:32:31 GMT Subject: RFR: 8283232: x86: Improve vector broadcast operations [v13] In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 13:48:07 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch improves the generation of broadcasting a scalar in several ways: >> >> - As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines. >> - Vector broadcasting should prefer rematerialising to spilling when register pressure is high. >> - Load vectors using the same kind (integral vs floating point) of instructions as that of the results to avoid potential data bypass delay >> >> With this patch, the result of the added benchmark, which performs some operations with a really high register pressure, on my machine with Intel i7-7700HQ (avx2) is as follow: >> >> Before After >> Benchmark Mode Cnt Score Error Score Error Units Gain >> SpiltReplicate.testDouble avgt 5 42.621 ? 0.598 38.771 ? 0.797 ns/op +9.03% >> SpiltReplicate.testFloat avgt 5 42.245 ? 1.464 38.603 ? 0.367 ns/op +8.62% >> SpiltReplicate.testInt avgt 5 20.581 ? 5.791 13.755 ? 0.375 ns/op +33.17% >> SpiltReplicate.testLong avgt 5 17.794 ? 4.781 13.663 ? 0.387 ns/op +23.22% >> >> As expected, the constant table sizes shrink significantly from 1024 bytes to 256 bytes for `long`/`double` and 128 bytes for `int`/`float` cases. >> >> This patch also removes some redundant code paths and renames some incorrectly named instructions. >> >> Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > add load_constant_vector I submitted new testing for version 012. Last update was not simple. ------------- PR: https://git.openjdk.org/jdk/pull/7832 From dholmes at openjdk.org Tue Aug 2 01:14:47 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Aug 2022 01:14:47 GMT Subject: RFR: 8291654: AArch64: assert from JDK-8287393 causes crashes In-Reply-To: References: Message-ID: <4DcY00u_iF6gEa8yVjQZp9ctRVDNft1l5pWkWGJZFKw=.6b95c1e8-7c11-49f8-96e5-1878485bdaf2@github.com> On Mon, 1 Aug 2022 23:53:05 GMT, Vladimir Kozlov wrote: >> https://github.com/openjdk/jdk/commit/6cbc234ad17c5a0c4b3d6ea76f807c27c1dc8330 adds an assert checking `in_scratch_emit_size` is set during the output phase of C2 compilation. The assert can fail if C1 uses `trampoline_call`. >> The assert is not needed as the calculation of `in_scratch_emit_size` is short-circuited to false if it is C1. > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 883: > >> 881: assert(StubRoutines::aarch64::complete() && >> 882: Thread::current()->is_Compiler_thread() && >> 883: Compile::current()->output() != NULL, "not in output phase of C2 compilation"); > > The code is under `#ifdef COMPILER2` which assumes that it is executed only for C2. Which make it confusing because it CAN be executed by C1. > There is check at line 885 `is_c2_compile()` which is true only for C2. May be we can rearrange code to make it less confusing. > On other hand if `check_emit_size` could be `true` for C1 why we should emit trampoline for it and not for C2? @vnkozlov I will leave it to you to decide whether to sponsor as-is or look for additional changes. The failures seem intermittent and have not re-occurred in the next two CI runs. ------------- PR: https://git.openjdk.org/jdk/pull/9709 From thartmann at openjdk.org Tue Aug 2 06:11:55 2022 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 2 Aug 2022 06:11:55 GMT Subject: RFR: 8291597: [BACKOUT] JDK-8289996: Fix array range check hoisting for some scaled loop iv In-Reply-To: References: Message-ID: <6_6Ir_A3HM3i4lfuKNoCEjn-M-9bSvmZFTUovYL0RO0=.f77cefc9-1e83-495f-91f4-186bfc1b5ea3@github.com> On Mon, 1 Aug 2022 04:09:43 GMT, Pengfei Li wrote: > This reverts JDK-8289996 as multiple jtreg fails after that change. Looks good. Vladimir's testing passed. The backout issue needs to be a sub-task. Please follow the steps described by https://openjdk.org/guide/#backing-out-a-change. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.org/jdk/pull/9696 From mbaesken at openjdk.org Tue Aug 2 06:38:59 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 2 Aug 2022 06:38:59 GMT Subject: RFR: 8291633: Build failures with GCC 11, Alpine 3 due to incompatible casts from nullptr In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 17:01:51 GMT, Aleksey Shipilev wrote: > Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. > > They fall into three categories: > - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does; > - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it; > - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead. > > Additional testing: > - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15, GCC 11.2.1 > - [x] Linux x86_64 fastdebug tier1 with GCC 9.3.0 Looks good to me, thanks for looking into it. ------------- Marked as reviewed by mbaesken (Reviewer). PR: https://git.openjdk.org/jdk/pull/9705 From dholmes at openjdk.org Tue Aug 2 06:41:24 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Aug 2022 06:41:24 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 18:51:10 GMT, Harold Seigel wrote: >> Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. >> >> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's src/java.base/share/classes/java/lang/Class.java line 4682: > 4680: */ > 4681: private int getClassFileVersion() { > 4682: Class component = isArray() ? elementType() : this; The variable name `component` seems completely not applicable now. I would just use `c`. test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 67: > 65: if (ver != 64) { > 66: int got_minor = (ver >> 16) & 0x0000FFFF; > 67: int got_major = ver & 0x0000FFFF; `got` seems odd in this context as these are not boolean queries. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From dholmes at openjdk.org Tue Aug 2 06:41:27 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Aug 2022 06:41:27 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v2] In-Reply-To: <9bk3CPQqVLEwoDzrdWzA7dF9682yMOSwZb-5xlVMfd4=.1c4e7037-ddd0-446f-b424-6d2634be41f4@github.com> References: <9bk3CPQqVLEwoDzrdWzA7dF9682yMOSwZb-5xlVMfd4=.1c4e7037-ddd0-446f-b424-6d2634be41f4@github.com> Message-ID: <-gW3vuFzomOO_l2wD8Z4Y98ZpWWhslmUKB0_7IBnQXM=.2f3ddef7-1063-4d80-a56a-b26d85855c7c@github.com> On Mon, 1 Aug 2022 13:26:29 GMT, Harold Seigel wrote: >> src/java.base/share/classes/java/lang/Class.java line 4698: >> >>> 4696: * >>> 4697: * If the class is an array type then the access flags of the component type is >>> 4698: * returned. If the class is a primitive then ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC. >> >> The `ACC_ABSTRACT` seems odd - is that way of indicating this "class" can't be instantiated? Is there some spec document that explains this choice? > > I don't know why API's such as JVM_GetClassModifiers() and JVM_GetClassAccessFlags return ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC for primitives. Nor could I find a spec that discussed access flags for primitives. But, I didn't want to change what's been returned for primitives in existing code. Interesting. `Class.getModifiers()` does not specify `ACC_ABSTRACT` so this seems to be something implementation specific (although no doubt a long standing situation.) >> test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 55: >> >>> 53: >>> 54: testIt("Version64", 64); >>> 55: testIt("Version59", 59); >> >> Any particular reason to choose 59? Shouldn't there also be tests for non-zero minor versions? > > No particular reason for choosing 59 other than it's different and less than 64. Test case Version64_65535 has a non-zero minor version. I think we should be testing for other real classfile versions that may be encountered, such as 45.3 ------------- PR: https://git.openjdk.org/jdk/pull/9688 From iklam at openjdk.org Tue Aug 2 06:46:38 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Aug 2022 06:46:38 GMT Subject: RFR: 8290840: Refactor the "os" class [v4] In-Reply-To: References: Message-ID: > Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. > > The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. > > This RFE tries to address the following: > > - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. > - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. Ioi Lam has updated the pull request incrementally with four additional commits since the last revision: - clarify comment - PLATFORM_PRINT_NATIVE_STACK -> HAVE_PLATFORM_PRINT_NATIVE_STACK - simplified rarely-defined function os::resolve_function_descriptor() - Made workaround_expand_exec_shield_cs_limit() a static function in os_linux.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9600/files - new: https://git.openjdk.org/jdk/pull/9600/files/560e67c9..1c7f8ebe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=02-03 Stats: 221 lines in 12 files changed: 89 ins; 118 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9600/head:pull/9600 PR: https://git.openjdk.org/jdk/pull/9600 From iklam at openjdk.org Tue Aug 2 06:46:44 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Aug 2022 06:46:44 GMT Subject: RFR: 8290840: Refactor the "os" class [v3] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 18:55:59 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed typo > > src/hotspot/os/aix/os_aix.hpp line 180: > >> 178: static bool get_meminfo(meminfo_t* pmi); >> 179: >> 180: // PPC only > > Since your are here, remove comment? There has not been an AIX on something other than power for ~25 years. Fixed > src/hotspot/os/aix/os_aix.inline.hpp line 37: > >> 35: inline bool os::zero_page_read_protected() { >> 36: return false; >> 37: } > > I have the feeling many of these functions are really just global constants and that the coding could be simplified further in followup RFEs. Yeah lets do more clean up in follow-up RFEs. > src/hotspot/os/linux/os_linux.cpp line 4492: > >> 4490: // perform the workaround >> 4491: Linux::capture_initial_stack(JavaThread::stack_size_at_create()); >> 4492: Linux::workaround_expand_exec_shield_cs_limit(); > > You could move `workaround_expand_exec_shield_cs_limit()` into this file, declare it static, and remove all mentionings from headers. It now lives in os_linux_x86.cpp, but since it has to be wrapped with !zero !64bit already it is an odd misfit anyway. So its not much more "wrong" for it to live here. Fixed. > src/hotspot/share/runtime/os.hpp line 92: > >> 90: // The Porting APIs declared as "inline" in os.hpp must be >> 91: // implemented in one of the two .inline.hpp files, depending on whether >> 92: // the feature is generic to the OS, or specific to a particular CPU > > generic? Did you mean specific? E.g. "depending on whether the feature is specific to a certain OS or an OS+CPU combination" ? I clarified the comment: // The Porting APIs declared as "inline" in os.hpp must be // implemented in one of the two .inline.hpp files, depending on // whether the feature is specific to a particular CPU architecture // for this OS. > src/hotspot/share/runtime/os.inline.hpp line 37: > >> 35: // Provide default empty implementation. >> 36: >> 37: #ifndef PLATFORM_PRINT_NATIVE_STACK > > Could you rename this to HAVE_PLATFORM_PRINT_NATIVE_STACK? Fixed ------------- PR: https://git.openjdk.org/jdk/pull/9600 From kvn at openjdk.org Tue Aug 2 06:50:56 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 2 Aug 2022 06:50:56 GMT Subject: RFR: 8291597: [BACKOUT] JDK-8289996: Fix array range check hoisting for some scaled loop iv In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:09:43 GMT, Pengfei Li wrote: > This reverts JDK-8289996 as multiple jtreg fails after that change. Testing passed. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9696 From pli at openjdk.org Tue Aug 2 06:50:59 2022 From: pli at openjdk.org (Pengfei Li) Date: Tue, 2 Aug 2022 06:50:59 GMT Subject: RFR: 8291597: [BACKOUT] JDK-8289996: Fix array range check hoisting for some scaled loop iv In-Reply-To: <6_6Ir_A3HM3i4lfuKNoCEjn-M-9bSvmZFTUovYL0RO0=.f77cefc9-1e83-495f-91f4-186bfc1b5ea3@github.com> References: <6_6Ir_A3HM3i4lfuKNoCEjn-M-9bSvmZFTUovYL0RO0=.f77cefc9-1e83-495f-91f4-186bfc1b5ea3@github.com> Message-ID: On Tue, 2 Aug 2022 06:08:29 GMT, Tobias Hartmann wrote: > The backout issue needs to be a sub-task. Please follow the steps described by https://openjdk.org/guide/#backing-out-a-change. Thanks for reminding. It's a sub-task now. ------------- PR: https://git.openjdk.org/jdk/pull/9696 From pli at openjdk.org Tue Aug 2 06:51:00 2022 From: pli at openjdk.org (Pengfei Li) Date: Tue, 2 Aug 2022 06:51:00 GMT Subject: RFR: 8291597: [BACKOUT] JDK-8289996: Fix array range check hoisting for some scaled loop iv In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:09:43 GMT, Pengfei Li wrote: > This reverts JDK-8289996 as multiple jtreg fails after that change. Thank you for the review. I will do the backout now and add a REDO later after investigations. ------------- PR: https://git.openjdk.org/jdk/pull/9696 From dholmes at openjdk.org Tue Aug 2 06:51:12 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Aug 2022 06:51:12 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v2] In-Reply-To: <9bk3CPQqVLEwoDzrdWzA7dF9682yMOSwZb-5xlVMfd4=.1c4e7037-ddd0-446f-b424-6d2634be41f4@github.com> References: <9bk3CPQqVLEwoDzrdWzA7dF9682yMOSwZb-5xlVMfd4=.1c4e7037-ddd0-446f-b424-6d2634be41f4@github.com> Message-ID: On Mon, 1 Aug 2022 13:30:21 GMT, Harold Seigel wrote: >> src/hotspot/share/prims/jvm.cpp line 4064: >> >>> 4062: assert(c->is_instance_klass(), "must be"); >>> 4063: InstanceKlass* ik = InstanceKlass::cast(c); >>> 4064: return (ik->minor_version() << 16) | ik->major_version(); >> >> I'm curious why the format is minor:major rather than major:minor ? > > This was requested by @RogerRiggs > > Major high vs low bits requires either: > High bits: val >>>16 > Low bits: val & 0xffff > > Except for preview, the minor version is 0, so putting major version in the low bits allows trivial comparison (without masking); but may lead to bugs due to carelessness. Okay makes sense. >> test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 31: >> >>> 29: * @modules java.base/java.lang:open >>> 30: * @compile classFileVersions.jcod >>> 31: * @run main/othervm --enable-preview ClassFileVersionTest >> >> What preview feature is being used here? > > No preview feature is being used but --enable-preview is needed here for the JVM to accept a class with a minor version of 65535. Ah I see. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From pli at openjdk.org Tue Aug 2 06:54:19 2022 From: pli at openjdk.org (Pengfei Li) Date: Tue, 2 Aug 2022 06:54:19 GMT Subject: Integrated: 8291597: [BACKOUT] JDK-8289996: Fix array range check hoisting for some scaled loop iv In-Reply-To: References: Message-ID: <4oBYtnVcPQRV1VRo1Y0AsrDNMmC1g4eYTCV_8-pSoGk=.af9eb4c9-74d3-4dde-87fd-492efc8f2fb4@github.com> On Mon, 1 Aug 2022 04:09:43 GMT, Pengfei Li wrote: > This reverts JDK-8289996 as multiple jtreg fails after that change. This pull request has now been integrated. Changeset: a2cff263 Author: Pengfei Li URL: https://git.openjdk.org/jdk/commit/a2cff2634cdaa0fa7ba2a1acd951d6f521f59f6d Stats: 193 lines in 4 files changed: 2 ins; 186 del; 5 mod 8291597: [BACKOUT] JDK-8289996: Fix array range check hoisting for some scaled loop iv Reviewed-by: kvn, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/9696 From dholmes at openjdk.org Tue Aug 2 06:54:42 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Aug 2022 06:54:42 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 18:51:31 GMT, Harold Seigel wrote: >> test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 45: >> >>> 43: if (ver != expectedResult) { >>> 44: throw new RuntimeException( >>> 45: "expected " + expectedResult + ", got " + ver + " for class " + className); >> >> It would be clearer to show the expected and actual in minor:major format. That way if the test fails we can easily see which bit is wrong. > > Changed to display as major:minor version. Seems odd to display as major:minor when it is stored as minor:majpor ------------- PR: https://git.openjdk.org/jdk/pull/9688 From stuefe at openjdk.org Tue Aug 2 06:56:37 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 2 Aug 2022 06:56:37 GMT Subject: RFR: 8290840: Refactor the "os" class [v4] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 06:46:38 GMT, Ioi Lam wrote: >> Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. >> >> The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. >> >> This RFE tries to address the following: >> >> - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. >> - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. > > Ioi Lam has updated the pull request incrementally with four additional commits since the last revision: > > - clarify comment > - PLATFORM_PRINT_NATIVE_STACK -> HAVE_PLATFORM_PRINT_NATIVE_STACK > - simplified rarely-defined function os::resolve_function_descriptor() > - Made workaround_expand_exec_shield_cs_limit() a static function in os_linux.cpp Still good. src/hotspot/os/linux/os_linux.cpp line 4476: > 4474: * @see JDK-8023956 > 4475: */ > 4476: void workaround_expand_exec_shield_cs_limit() { Make static? ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/9600 From iklam at openjdk.org Tue Aug 2 06:56:38 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Aug 2022 06:56:38 GMT Subject: RFR: 8290840: Refactor the "os" class [v3] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 19:22:28 GMT, Thomas Stuefe wrote: > Very good work. Only small remarks/nitpickings. > > One question though, how does it work if I want to use an API implemented on a per-platform base in shared code? E.g. `zero_page_read_protected()`? I include `os.hpp` to get the definition, but how do I get the implementation? I have to include the platform-specific inline header too? Still with the OS_HEADER macro? > > Cheers, Thomas I think we should avoid creating non-portable os::xxx APIs and then call them from shared code. There were some calls to os::Posix::xxx from the shared code that I fixed in this PR. If you really want to make a platform-specific call, you should just do this (sadly we have many such cases) #ifdef LINUX linux_blah(); #endif Putting linux_blah() into the os class seems pointless. ------------- PR: https://git.openjdk.org/jdk/pull/9600 From dholmes at openjdk.org Tue Aug 2 07:03:53 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Aug 2022 07:03:53 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v2] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 06:38:11 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's > > test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 67: > >> 65: if (ver != 64) { >> 66: int got_minor = (ver >> 16) & 0x0000FFFF; >> 67: int got_major = ver & 0x0000FFFF; > > `got` seems odd in this context as these are not boolean queries. Sorry I "got" it now :) ------------- PR: https://git.openjdk.org/jdk/pull/9688 From iklam at openjdk.org Tue Aug 2 07:04:04 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Aug 2022 07:04:04 GMT Subject: RFR: 8290840: Refactor the "os" class [v4] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 06:53:49 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request incrementally with four additional commits since the last revision: >> >> - clarify comment >> - PLATFORM_PRINT_NATIVE_STACK -> HAVE_PLATFORM_PRINT_NATIVE_STACK >> - simplified rarely-defined function os::resolve_function_descriptor() >> - Made workaround_expand_exec_shield_cs_limit() a static function in os_linux.cpp > > Still good. @tstuefe @gerard-ziemski I've simplified `os::resolve_function_descriptor()` according to your suggestions, but I changed the #ifdefs to be more exact: // Used only on PPC for AIX, or LINUX (ppc but not ppcle). static void* resolve_function_descriptor(void* p) #if defined(PPC) && (defined(AIX) || (defined(LINUX) && !defined(ABI_ELFv2))) ; #else { return NULL; } #endif If we use "#if defined(PPC) && !defined(ABI_ELFv2)))" it would be very difficult to understand. To be honest, I am not a big fan of adding #ifdefs into os.hpp just to save a few lines of code. The #ifdefs are hard to understand. They are also fragile if you need to add a new platform that also support this functionality. I am (semi) OK with doing this for resolve_function_descriptor(), as that's a PPC-only thing that's unlikely to apply for other platforms. However, I don't want to use the same pattern for os::platform_print_native_stack() because we may want to implement this for other planforms. ------------- PR: https://git.openjdk.org/jdk/pull/9600 From iklam at openjdk.org Tue Aug 2 07:07:54 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Aug 2022 07:07:54 GMT Subject: RFR: 8290840: Refactor the "os" class [v5] In-Reply-To: References: Message-ID: > Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. > > The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. > > This RFE tries to address the following: > > - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. > - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9600/files - new: https://git.openjdk.org/jdk/pull/9600/files/1c7f8ebe..06ae96b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9600/head:pull/9600 PR: https://git.openjdk.org/jdk/pull/9600 From pli at openjdk.org Tue Aug 2 07:10:12 2022 From: pli at openjdk.org (Pengfei Li) Date: Tue, 2 Aug 2022 07:10:12 GMT Subject: RFR: 8291597: [BACKOUT] JDK-8289996: Fix array range check hoisting for some scaled loop iv In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:09:43 GMT, Pengfei Li wrote: > This reverts JDK-8289996 as multiple jtreg fails after that change. I've moved the BACKOUT to a sub-task of REDO now. ------------- PR: https://git.openjdk.org/jdk/pull/9696 From dholmes at openjdk.org Tue Aug 2 07:12:38 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Aug 2022 07:12:38 GMT Subject: RFR: 8290840: Refactor the "os" class [v5] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 07:07:54 GMT, Ioi Lam wrote: >> Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. >> >> The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. >> >> This RFE tries to address the following: >> >> - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. >> - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed whitespace Still seems okay to me. src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp line 520: > 518: } > 519: > 520: #if !defined(ABI_ELFv2) I don't think many people will be able to map this to any specific platform. At a minimum some comment is needed to explain this. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9600 From stuefe at openjdk.org Tue Aug 2 07:15:07 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 2 Aug 2022 07:15:07 GMT Subject: RFR: 8290840: Refactor the "os" class [v3] In-Reply-To: References: Message-ID: <-wRbV7feLdw6g3Thx5dYZ419KBmQ60TalieMj7AecAA=.ff3d7140-e16e-49a3-bf64-b3f1f559c601@github.com> On Tue, 2 Aug 2022 06:50:51 GMT, Ioi Lam wrote: > > I think we should avoid creating non-portable os::xxx APIs and then call them from shared code. There were some calls to os::Posix::xxx from the shared code that I fixed in this PR. I don't think that's what I meant. I meant APIs that exist for all OSes but have different expressions on each OS. So the prototype should live in shared os. But I want to pull a different implementation for each OS. This only affects inline functions. If the different implementations live in os_xx.cpp it works automatically through link time resolution. I see there are only a few examples for what I meant. Many inline functions return platform dependend values that those live in variables in shared code (e.g. os::vm_page_size(), ...). Others are just not inline (os.create_thread(), ...). Which leaves us with the likes of `zero_page_read_protected()` etc, and I see you put them into os.inline.hpp and there you include the OS specific headers too. I guess this can mostly be avoided. E.g. there is zero reason why `zero_page_read_protected()` cannot be a static boolean variable in os. For future RFEs. ------------- PR: https://git.openjdk.org/jdk/pull/9600 From shade at openjdk.org Tue Aug 2 08:26:38 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 2 Aug 2022 08:26:38 GMT Subject: [jdk19] RFR: 8288759: GCC 12 fails to compile signature.cpp due to -Wstringop-overread [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 12:12:40 GMT, Aleksey Shipilev wrote: >> Trying to compile with GCC 12.1.1 (current Fedora Rawhide) yields this failure: >> >> >> In file included from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions_gcc.hpp:35, >> from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions.hpp:35, >> from /home/test/shipilev-jdk/src/hotspot/share/memory/allocation.hpp:29, >> from /home/test/shipilev-jdk/src/hotspot/share/classfile/classLoaderData.hpp:28, >> from /home/test/shipilev-jdk/src/hotspot/share/precompiled/precompiled.hpp:34: >> In function 'const void* memchr(const void*, int, size_t)', >> inlined from 'int SignatureStream::scan_type(BasicType)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:343:32, >> inlined from 'void SignatureStream::next()' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:373:19, >> inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:635:41, >> inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:629:6, >> inlined from 'void Fingerprinter::compute_fingerprint_and_return_type(bool)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:169:19: > > 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: > > - Better fix the actual warning > - Merge branch 'master' into JDK-8288759-gcc12-string-overread > - Fix Closed in favor of https://github.com/openjdk/jdk/pull/9711 ------------- PR: https://git.openjdk.org/jdk19/pull/49 From shade at openjdk.org Tue Aug 2 08:26:40 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 2 Aug 2022 08:26:40 GMT Subject: [jdk19] Withdrawn: 8288759: GCC 12 fails to compile signature.cpp due to -Wstringop-overread In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 17:58:49 GMT, Aleksey Shipilev wrote: > Trying to compile with GCC 12.1.1 (current Fedora Rawhide) yields this failure: > > > In file included from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions_gcc.hpp:35, > from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions.hpp:35, > from /home/test/shipilev-jdk/src/hotspot/share/memory/allocation.hpp:29, > from /home/test/shipilev-jdk/src/hotspot/share/classfile/classLoaderData.hpp:28, > from /home/test/shipilev-jdk/src/hotspot/share/precompiled/precompiled.hpp:34: > In function 'const void* memchr(const void*, int, size_t)', > inlined from 'int SignatureStream::scan_type(BasicType)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:343:32, > inlined from 'void SignatureStream::next()' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:373:19, > inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:635:41, > inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:629:6, > inlined from 'void Fingerprinter::compute_fingerprint_and_return_type(bool)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:169:19: This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk19/pull/49 From aph at openjdk.org Tue Aug 2 08:37:51 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 2 Aug 2022 08:37:51 GMT Subject: RFR: 8291654: AArch64: assert from JDK-8287393 causes crashes In-Reply-To: <4DcY00u_iF6gEa8yVjQZp9ctRVDNft1l5pWkWGJZFKw=.6b95c1e8-7c11-49f8-96e5-1878485bdaf2@github.com> References: <4DcY00u_iF6gEa8yVjQZp9ctRVDNft1l5pWkWGJZFKw=.6b95c1e8-7c11-49f8-96e5-1878485bdaf2@github.com> Message-ID: On Tue, 2 Aug 2022 01:12:44 GMT, David Holmes wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 883: >> >>> 881: assert(StubRoutines::aarch64::complete() && >>> 882: Thread::current()->is_Compiler_thread() && >>> 883: Compile::current()->output() != NULL, "not in output phase of C2 compilation"); >> >> The code is under `#ifdef COMPILER2` which assumes that it is executed only for C2. Which make it confusing because it CAN be executed by C1. >> There is check at line 885 `is_c2_compile()` which is true only for C2. May be we can rearrange code to make it less confusing. >> On other hand if `check_emit_size` could be `true` for C1 why we should emit trampoline for it and not for C2? > > @vnkozlov I will leave it to you to decide whether to sponsor as-is or look for additional changes. The failures seem intermittent and have not re-occurred in the next two CI runs. Leave it out. It does nothing useful; I think it was just a precaution. ------------- PR: https://git.openjdk.org/jdk/pull/9709 From duke at openjdk.org Tue Aug 2 10:41:49 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 2 Aug 2022 10:41:49 GMT Subject: RFR: 8291654: AArch64: assert from JDK-8287393 causes crashes In-Reply-To: References: <4DcY00u_iF6gEa8yVjQZp9ctRVDNft1l5pWkWGJZFKw=.6b95c1e8-7c11-49f8-96e5-1878485bdaf2@github.com> Message-ID: On Tue, 2 Aug 2022 08:33:30 GMT, Andrew Haley wrote: >> @vnkozlov I will leave it to you to decide whether to sponsor as-is or look for additional changes. The failures seem intermittent and have not re-occurred in the next two CI runs. > > Leave it out. It does nothing useful; I think it was just a precaution. > The failures seem intermittent and have not re-occurred in the next two CI runs. @dholmes-ora It is intermittent because we get unlucky and `Compile::current()->output()` either crashes or returns `NULL`. ------------- PR: https://git.openjdk.org/jdk/pull/9709 From phh at openjdk.org Tue Aug 2 12:00:09 2022 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 2 Aug 2022 12:00:09 GMT Subject: RFR: 8291654: AArch64: assert from JDK-8287393 causes crashes In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 22:13:53 GMT, Evgeny Astigeevich wrote: > https://github.com/openjdk/jdk/commit/6cbc234ad17c5a0c4b3d6ea76f807c27c1dc8330 adds an assert checking `in_scratch_emit_size` is set during the output phase of C2 compilation. The assert can fail if C1 uses `trampoline_call`. > The assert is not needed as the calculation of `in_scratch_emit_size` is short-circuited to false if it is C1. Lgtm. ------------- Marked as reviewed by phh (Reviewer). PR: https://git.openjdk.org/jdk/pull/9709 From duke at openjdk.org Tue Aug 2 12:04:30 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 2 Aug 2022 12:04:30 GMT Subject: Integrated: 8291654: AArch64: assert from JDK-8287393 causes crashes In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 22:13:53 GMT, Evgeny Astigeevich wrote: > https://github.com/openjdk/jdk/commit/6cbc234ad17c5a0c4b3d6ea76f807c27c1dc8330 adds an assert checking `in_scratch_emit_size` is set during the output phase of C2 compilation. The assert can fail if C1 uses `trampoline_call`. > The assert is not needed as the calculation of `in_scratch_emit_size` is short-circuited to false if it is C1. This pull request has now been integrated. Changeset: af76c0c1 Author: Evgeny Astigeevich Committer: Paul Hohensee URL: https://git.openjdk.org/jdk/commit/af76c0c1991f6051ba95f05b79121a7eeef8e7d3 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8291654: AArch64: assert from JDK-8287393 causes crashes Reviewed-by: dholmes, xliu, phh ------------- PR: https://git.openjdk.org/jdk/pull/9709 From hseigel at openjdk.org Tue Aug 2 12:50:05 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 2 Aug 2022 12:50:05 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v2] In-Reply-To: References: Message-ID: <1e2Wlr-NZZrEOHOFHhcswO8e2N4OQfcVKUnCD6f7tag=.cf3f451c-6ec7-4164-a3e3-39146a954e75@github.com> On Tue, 2 Aug 2022 06:51:46 GMT, David Holmes wrote: >> Changed to display as major:minor version. > > Seems odd to display as major:minor when it is stored as minor:major I think it seems more natural to display the major version first, but I can change it if you prefer. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From duke at openjdk.org Tue Aug 2 13:52:51 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 2 Aug 2022 13:52:51 GMT Subject: RFR: 8291654: AArch64: assert from JDK-8287393 causes crashes In-Reply-To: References: Message-ID: <-Pww2K5Wc10ygAnecPvz8js2lQQmoxjow20dDILXq7c=.77017e1a-c203-4ae4-9498-4a5b74aa1649@github.com> On Mon, 1 Aug 2022 23:53:05 GMT, Vladimir Kozlov wrote: >> https://github.com/openjdk/jdk/commit/6cbc234ad17c5a0c4b3d6ea76f807c27c1dc8330 adds an assert checking `in_scratch_emit_size` is set during the output phase of C2 compilation. The assert can fail if C1 uses `trampoline_call`. >> The assert is not needed as the calculation of `in_scratch_emit_size` is short-circuited to false if it is C1. > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 883: > >> 881: assert(StubRoutines::aarch64::complete() && >> 882: Thread::current()->is_Compiler_thread() && >> 883: Compile::current()->output() != NULL, "not in output phase of C2 compilation"); > > The code is under `#ifdef COMPILER2` which assumes that it is executed only for C2. Which make it confusing because it CAN be executed by C1. > There is check at line 885 `is_c2_compile()` which is true only for C2. May be we can rearrange code to make it less confusing. > On other hand if `check_emit_size` could be `true` for C1 why we should emit trampoline for it and not for C2? @vnkozlov > On other hand if `check_emit_size` could be `true` for C1 why we should emit trampoline for it and not for C2? IMHO `check_emit_size` should always be `false` for C1 because C1 does not have such functionality. This was not caught by testing. The problem is what the default value `check_emit_size` should have. The current default value `true` leads to confusion for the cases where 'check emit size' has no meaning like C1 or stub generation. A possible solution simplifying everything can be: virtual bool MacroAssembler::emit_trampoline_stub(...) { The default implementation which always generates a trampoline code. } address MacroAssembler::trampoline_call(Address entry, CodeBuffer* cbuf) { bool need_trampoline = far_branches(); if (!need_trampoline && entry.rspec().type() == relocInfo::runtime_call_type && !CodeCache::contains(entry.target())) { ... } if (cbuf) cbuf->set_insts_mark(); relocate(entry.rspec()); if (!need_trampoline) { bl(entry.target()); } else { if (!emit_trampoline_stub(offset(), entry.target())) { postcond(pc() == badAddress); return NULL; // CodeCache is full } bl(pc()); } // just need to return a non-null address postcond(pc() != badAddress); return pc(); } bool C2_MacroAssembler::emit_trampoline_stub(...) { auto phase_output = Compile::current()->output(); if (phase_output !=NULL && phase_output->in_scratch_emit_size()) { // We don't want to emit a trampoline if C2 is generating dummy // code during its branch shortening phase. return true; } return MacroAssembler::emit_trampoline_stub(...); } I can submit PR with it if there is interest in the solution. What do you think? ------------- PR: https://git.openjdk.org/jdk/pull/9709 From hseigel at openjdk.org Tue Aug 2 14:12:44 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 2 Aug 2022 14:12:44 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v3] In-Reply-To: References: Message-ID: > Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. > > The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: add test case, minor renames ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9688/files - new: https://git.openjdk.org/jdk/pull/9688/files/82890e56..941971dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9688&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9688&range=01-02 Stats: 95 lines in 3 files changed: 91 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9688.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9688/head:pull/9688 PR: https://git.openjdk.org/jdk/pull/9688 From hseigel at openjdk.org Tue Aug 2 14:12:46 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 2 Aug 2022 14:12:46 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v2] In-Reply-To: References: Message-ID: <8_Jv1YwCxG5wGqtticVYokITBBJURYX0F8YYZQNv01o=.c3941281-9998-453b-82a7-5cfa3a2cc846@github.com> On Tue, 2 Aug 2022 06:24:10 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> Improved tests, added mulit-dimensional array tests, simplified new java.lang.Class API's > > src/java.base/share/classes/java/lang/Class.java line 4682: > >> 4680: */ >> 4681: private int getClassFileVersion() { >> 4682: Class component = isArray() ? elementType() : this; > > The variable name `component` seems completely not applicable now. I would just use `c`. Done. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From hseigel at openjdk.org Tue Aug 2 14:12:47 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 2 Aug 2022 14:12:47 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v3] In-Reply-To: <-gW3vuFzomOO_l2wD8Z4Y98ZpWWhslmUKB0_7IBnQXM=.2f3ddef7-1063-4d80-a56a-b26d85855c7c@github.com> References: <9bk3CPQqVLEwoDzrdWzA7dF9682yMOSwZb-5xlVMfd4=.1c4e7037-ddd0-446f-b424-6d2634be41f4@github.com> <-gW3vuFzomOO_l2wD8Z4Y98ZpWWhslmUKB0_7IBnQXM=.2f3ddef7-1063-4d80-a56a-b26d85855c7c@github.com> Message-ID: On Tue, 2 Aug 2022 06:36:54 GMT, David Holmes wrote: >> No particular reason for choosing 59 other than it's different and less than 64. Test case Version64_65535 has a non-zero minor version. > > I think we should be testing for other real classfile versions that may be encountered, such as 45.3 I added a test case for 45.3. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From duke at openjdk.org Tue Aug 2 14:23:11 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Tue, 2 Aug 2022 14:23:11 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: <7ZWXnITgRa_WubtuwnM3VTs62HqwzbMOUt9Tdp9Fx-s=.d3e48748-36fc-4ce1-a096-5830afa1c29d@github.com> On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From duke at openjdk.org Tue Aug 2 14:39:07 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Tue, 2 Aug 2022 14:39:07 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading Message-ID: @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) Description from the original issue: > The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. > > Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. > > It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. Testing: Tier 1-3 Will run test tier 4-7 ------------- Commit messages: - 8291718: Remove mark_for_deoptimization from klass unloading Changes: https://git.openjdk.org/jdk/pull/9713/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291718 Stats: 49 lines in 3 files changed: 28 ins; 9 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9713.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9713/head:pull/9713 PR: https://git.openjdk.org/jdk/pull/9713 From rriggs at openjdk.org Tue Aug 2 14:45:55 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 2 Aug 2022 14:45:55 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v3] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 14:12:44 GMT, Harold Seigel wrote: >> Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. >> >> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > add test case, minor renames LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9688 From kvn at openjdk.org Tue Aug 2 15:54:24 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 2 Aug 2022 15:54:24 GMT Subject: RFR: 8291654: AArch64: assert from JDK-8287393 causes crashes In-Reply-To: <-Pww2K5Wc10ygAnecPvz8js2lQQmoxjow20dDILXq7c=.77017e1a-c203-4ae4-9498-4a5b74aa1649@github.com> References: <-Pww2K5Wc10ygAnecPvz8js2lQQmoxjow20dDILXq7c=.77017e1a-c203-4ae4-9498-4a5b74aa1649@github.com> Message-ID: <-5AB5hBjKTSdYs-n-xuptTTT3-3r8W1_RX44ARwg2lc=.b24ca7a9-4cab-47d8-a8da-010ac93ce02d@github.com> On Tue, 2 Aug 2022 13:49:11 GMT, Evgeny Astigeevich wrote: > I can submit PR with it if there is interest in the solution. > What do you think? @eastig Please do that. Your code change suggestion is good. ------------- PR: https://git.openjdk.org/jdk/pull/9709 From iklam at openjdk.org Tue Aug 2 16:06:10 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Aug 2022 16:06:10 GMT Subject: RFR: 8290840: Refactor the "os" class [v6] In-Reply-To: References: Message-ID: > Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. > > The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. > > This RFE tries to address the following: > > - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. > - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. 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 13 additional commits since the last revision: - clarified comments about inline functions declared in os.hpp - Merge branch 'master' into 8290840-refactor-the-os-class - made workaround_expand_exec_shield_cs_limit() static; added PPC comments for os::resolve_function_descriptor() - fixed whitespace - clarify comment - PLATFORM_PRINT_NATIVE_STACK -> HAVE_PLATFORM_PRINT_NATIVE_STACK - simplified rarely-defined function os::resolve_function_descriptor() - Made workaround_expand_exec_shield_cs_limit() a static function in os_linux.cpp - fixed typo - moved os::{print_active_locale, print_user_info} to os_posix.cpp - ... and 3 more: https://git.openjdk.org/jdk/compare/0c02a00c...b6e60a54 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9600/files - new: https://git.openjdk.org/jdk/pull/9600/files/06ae96b9..b6e60a54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=04-05 Stats: 10587 lines in 497 files changed: 5791 ins; 3470 del; 1326 mod Patch: https://git.openjdk.org/jdk/pull/9600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9600/head:pull/9600 PR: https://git.openjdk.org/jdk/pull/9600 From iklam at openjdk.org Tue Aug 2 16:12:54 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Aug 2022 16:12:54 GMT Subject: RFR: 8290840: Refactor the "os" class [v3] In-Reply-To: <-wRbV7feLdw6g3Thx5dYZ419KBmQ60TalieMj7AecAA=.ff3d7140-e16e-49a3-bf64-b3f1f559c601@github.com> References: <-wRbV7feLdw6g3Thx5dYZ419KBmQ60TalieMj7AecAA=.ff3d7140-e16e-49a3-bf64-b3f1f559c601@github.com> Message-ID: On Tue, 2 Aug 2022 07:12:33 GMT, Thomas Stuefe wrote: > > I think we should avoid creating non-portable os::xxx APIs and then call them from shared code. There were some calls to os::Posix::xxx from the shared code that I fixed in this PR. > > I don't think that's what I meant. I meant APIs that exist for all OSes but have different expressions on each OS. So the prototype should live in shared os. But I want to pull a different implementation for each OS. > > This only affects inline functions. If the different implementations live in os_xx.cpp it works automatically through link time resolution. > > I see there are only a few examples for what I meant. Many inline functions return platform dependend values and those live in variables in shared code (e.g. os::vm_page_size(), ...). Others are just not inline (os.create_thread(), ...). Which leaves us with the likes of `zero_page_read_protected()` etc, and I see you put them into os.inline.hpp and there you include the OS specific headers too. > > I guess this can mostly be avoided. E.g. there is zero reason why `zero_page_read_protected()` cannot be a static boolean variable in os. For future RFEs. Thanks for pointing this out. I've updated the comments in os.hpp to be more clear about the inline functions. The design is -- if `os.hpp` declares an "inline" function without a body, the implementation must be in `os_.inline.hpp` or `os__.inline.hpp`. It's not possible for some platforms to choose to implement such a function in a .cpp file. Conversely, if a function is NOT declared "inline" in `os.hpp`, it must NOT be implemented in any of the `os*inline.hpp` files. Hence, any source file that references this function must include `os.inline.hpp`. Without such a rule, it's possible for the build to succeed on some platforms (especially if the compiler is more lenient on missing inline function definitions) and fail on others. As a result, it would be easier to break the repo as not everyone is able to build all platforms before integrating a PR. This rule is similar to how we handle "inline" declarations in regular HotSpot headers. ------------- PR: https://git.openjdk.org/jdk/pull/9600 From iklam at openjdk.org Tue Aug 2 16:12:55 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Aug 2022 16:12:55 GMT Subject: RFR: 8290840: Refactor the "os" class [v3] In-Reply-To: References: <-wRbV7feLdw6g3Thx5dYZ419KBmQ60TalieMj7AecAA=.ff3d7140-e16e-49a3-bf64-b3f1f559c601@github.com> Message-ID: On Tue, 2 Aug 2022 16:08:35 GMT, Ioi Lam wrote: > I see there are only a few examples for what I meant. Many inline functions return platform dependend values and those live in variables in shared code (e.g. os::vm_page_size(), ...). Others are just not inline (os.create_thread(), ...). Which leaves us with the likes of `zero_page_read_protected()` etc, and I see you put them into os.inline.hpp and there you include the OS specific headers too. > > I guess this can mostly be avoided. E.g. there is zero reason why `zero_page_read_protected()` cannot be a static boolean variable in os. For future RFEs. Yes, this can certainly be improved in follow-up RFE. ------------- PR: https://git.openjdk.org/jdk/pull/9600 From duke at openjdk.org Tue Aug 2 16:48:05 2022 From: duke at openjdk.org (Yi-Fan Tsai) Date: Tue, 2 Aug 2022 16:48:05 GMT Subject: RFR: 8280152: AArch64: Reuse runtime call trampolines [v7] In-Reply-To: <2Rz88X0uWMdi7N4NFC36ZiMXgOhUmh0XehnaOKo6JWM=.9422ee14-4e73-47a5-a211-842fa5331391@github.com> References: <2Rz88X0uWMdi7N4NFC36ZiMXgOhUmh0XehnaOKo6JWM=.9422ee14-4e73-47a5-a211-842fa5331391@github.com> Message-ID: > A trampoline stub could be generated for each runtime call. These trampolines could be duplication if the callees are the same. This change delays the stub generation and generates one stub for a distinct callee. > > Benchmark als, chi-square, dec-tree, gauss-mix, log-regression, movie-lens, naive-bayes, page-rank, fj-means, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~4.7% reduction on average. Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision: Grow hashtable only if a new entry is added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9405/files - new: https://git.openjdk.org/jdk/pull/9405/files/877ebb8b..40e51714 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9405&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9405&range=05-06 Stats: 6 lines in 1 file changed: 3 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9405.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9405/head:pull/9405 PR: https://git.openjdk.org/jdk/pull/9405 From stefank at openjdk.org Tue Aug 2 16:52:20 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 2 Aug 2022 16:52:20 GMT Subject: RFR: 8290840: Refactor the "os" class [v6] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 16:06:10 GMT, Ioi Lam wrote: >> Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. >> >> The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. >> >> This RFE tries to address the following: >> >> - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. >> - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. > > 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 13 additional commits since the last revision: > > - clarified comments about inline functions declared in os.hpp > - Merge branch 'master' into 8290840-refactor-the-os-class > - made workaround_expand_exec_shield_cs_limit() static; added PPC comments for os::resolve_function_descriptor() > - fixed whitespace > - clarify comment > - PLATFORM_PRINT_NATIVE_STACK -> HAVE_PLATFORM_PRINT_NATIVE_STACK > - simplified rarely-defined function os::resolve_function_descriptor() > - Made workaround_expand_exec_shield_cs_limit() a static function in os_linux.cpp > - fixed typo > - moved os::{print_active_locale, print_user_info} to os_posix.cpp > - ... and 3 more: https://git.openjdk.org/jdk/compare/eae2b95f...b6e60a54 I love seeing the os files being cleaned up and restructured. I started to look at the patch and found a significant number of nits that I think would be good to fix. src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 37: > 35: #include "nativeInst_zero.hpp" > 36: #include "os_posix.hpp" > 37: #include "os_linux.hpp" Sort src/hotspot/share/runtime/os.inline.hpp line 31: > 29: > 30: #include OS_HEADER(os) > 31: #include OS_HEADER_INLINE(os) We usually only explicitly include .inline.hpp and don't and let that file bring in the corresponding .hpp file. test/hotspot/gtest/runtime/test_os.cpp line 37: > 35: #include "runtime/frame.inline.hpp" > 36: #include "runtime/threads.hpp" > 37: Remove blank line ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.org/jdk/pull/9600 From stefank at openjdk.org Tue Aug 2 16:52:25 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 2 Aug 2022 16:52:25 GMT Subject: RFR: 8290840: Refactor the "os" class [v5] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 07:07:54 GMT, Ioi Lam wrote: >> Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. >> >> The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. >> >> This RFE tries to address the following: >> >> - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. >> - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed whitespace src/hotspot/os/posix/os_posix.cpp line 52: > 50: #include "utilities/macros.hpp" > 51: #include "utilities/vmError.hpp" > 52: Other files don't add a blank line before the conditional includes. src/hotspot/os/posix/os_posix.hpp line 29: > 27: > 28: #include "runtime/os.hpp" > 29: #include We usually add blank lines before system includes src/hotspot/os/posix/os_posix.inline.hpp line 30: > 28: #include "runtime/mutex.hpp" > 29: #include "runtime/os.hpp" > 30: #include "os_posix.hpp" The .hpp file of an .inline.hpp file should be included as the first include. The comment above was an indication that we previously didn't follow that rule, because of how we sometimes structure platform includes. But it seems like you are changing this now, and I hope that we now can follow that rule and change the code to: #include "os_posix.hpp" #include "runtime/mutex.hpp" #include "runtime/os.hpp" src/hotspot/os/posix/perfMemory_posix.cpp line 40: > 38: #include "services/memTracker.hpp" > 39: #include "utilities/exceptions.hpp" > 40: Remove blank line src/hotspot/os/posix/perfMemory_posix.cpp line 44: > 42: #include "os_linux.hpp" > 43: #endif > 44: It feels "wrong" that the posix files include linux files. Maybe that's something that future restructuring of code could fix. src/hotspot/os/posix/safefetch_static_posix.cpp line 31: > 29: #include "runtime/safefetch.hpp" > 30: #include "utilities/globalDefinitions.hpp" > 31: #include "os_posix.hpp" Not sorted include src/hotspot/os/posix/semaphore_posix.cpp line 28: > 26: #ifndef __APPLE__ > 27: #include "runtime/os.hpp" > 28: #include "os_posix.hpp" Sort src/hotspot/os/posix/signals_posix.cpp line 38: > 36: #include "runtime/javaThread.hpp" > 37: #include "runtime/os.hpp" > 38: #include "os_posix.hpp" Sort src/hotspot/os/posix/vmError_posix.cpp line 30: > 28: #include "runtime/javaThread.hpp" > 29: #include "runtime/os.hpp" > 30: #include "os_posix.hpp" Sort src/hotspot/os/windows/os_windows.inline.hpp line 33: > 31: #include "runtime/mutex.hpp" > 32: #include "runtime/os.hpp" > 33: #include "os_windows.hpp" Sort src/hotspot/os/windows/pdh_interface.cpp line 27: > 25: #include "precompiled.hpp" > 26: #include "pdh_interface.hpp" > 27: #include "os_windows.hpp" Sort src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 37: > 35: #include "memory/allocation.inline.hpp" > 36: #include "os_posix.hpp" > 37: #include "os_linux.hpp" Sort ------------- PR: https://git.openjdk.org/jdk/pull/9600 From coleenp at openjdk.org Tue Aug 2 16:55:22 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 2 Aug 2022 16:55:22 GMT Subject: RFR: 8291733: Remove JFR events that expose hashtable Message-ID: <-M--ixe6ZniductAe4Xa9CfUZ_2-Ggy2RS80VeBvWaE=.0cf3d639-91b1-4b25-a519-f1ec55e857b8@github.com> There are JFR events for the Placeholders table, LoaderConstraintTable and ProtectionDomainCacheTable. These events expose implementation details for these tables that we'd rather not expose. A users visibility into these tables will not be helpful and it restricts our ability to make these a different (smaller) table or in the case of ProtectionDomain, not a table at all. The Dictionary table (table of loaded classes) is useful from a users' perspective because it can be resized and we wanted to have events for the resizing. These other tables came along in that change. Tested with tier1-3. ------------- Commit messages: - 8291733: Remove JFR events that expose hashtable Changes: https://git.openjdk.org/jdk/pull/9714/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9714&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291733 Stats: 113 lines in 8 files changed: 0 ins; 111 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9714.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9714/head:pull/9714 PR: https://git.openjdk.org/jdk/pull/9714 From egahlin at openjdk.org Tue Aug 2 16:55:22 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 2 Aug 2022 16:55:22 GMT Subject: RFR: 8291733: Remove JFR events that expose hashtable In-Reply-To: <-M--ixe6ZniductAe4Xa9CfUZ_2-Ggy2RS80VeBvWaE=.0cf3d639-91b1-4b25-a519-f1ec55e857b8@github.com> References: <-M--ixe6ZniductAe4Xa9CfUZ_2-Ggy2RS80VeBvWaE=.0cf3d639-91b1-4b25-a519-f1ec55e857b8@github.com> Message-ID: On Tue, 2 Aug 2022 16:42:44 GMT, Coleen Phillimore wrote: > There are JFR events for the Placeholders table, LoaderConstraintTable and ProtectionDomainCacheTable. These events expose implementation details for these tables that we'd rather not expose. A users visibility into these tables will not be helpful and it restricts our ability to make these a different (smaller) table or in the case of ProtectionDomain, not a table at all. > > The Dictionary table (table of loaded classes) is useful from a users' perspective because it can be resized and we wanted to have events for the resizing. These other tables came along in that change. > > Tested with tier1-3. Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9714 From coleenp at openjdk.org Tue Aug 2 17:08:48 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 2 Aug 2022 17:08:48 GMT Subject: RFR: 8291733: Remove JFR events that expose hashtable In-Reply-To: References: <-M--ixe6ZniductAe4Xa9CfUZ_2-Ggy2RS80VeBvWaE=.0cf3d639-91b1-4b25-a519-f1ec55e857b8@github.com> Message-ID: On Tue, 2 Aug 2022 16:46:38 GMT, Erik Gahlin wrote: >> There are JFR events for the Placeholders table, LoaderConstraintTable and ProtectionDomainCacheTable. These events expose implementation details for these tables that we'd rather not expose. A users visibility into these tables will not be helpful and it restricts our ability to make these a different (smaller) table or in the case of ProtectionDomain, not a table at all. >> >> The Dictionary table (table of loaded classes) is useful from a users' perspective because it can be resized and we wanted to have events for the resizing. These other tables came along in that change. >> >> Tested with tier1-3. > > Marked as reviewed by egahlin (Reviewer). Thanks @egahlin ------------- PR: https://git.openjdk.org/jdk/pull/9714 From sangheki at openjdk.org Tue Aug 2 17:25:43 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Tue, 2 Aug 2022 17:25:43 GMT Subject: RFR: 8290357: Drop HeapRegion::marked_bytes() In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 11:06:27 GMT, Thomas Schatzl wrote: > Hi all, > > please review this removal of the `HeapRegion::_marked_bytes` member that records the bytes marked below tams in the recent mark as it is not really interesting in the removed places. I added comments to give reasons for this removal in the particular places for your review. > > Testing: jtreg gc/g1, gha > > Thanks, > Thomas src/hotspot/share/gc/g1/heapRegion.cpp line 276: > 274: bool during_conc_mark) { > 275: // We always scrub the region to make sure the entire region is > 276: // parsable after the self-forwarding point removal, and update _marked_bytes Need an update with _marked_bytes. ------------- PR: https://git.openjdk.org/jdk/pull/9511 From eosterlund at openjdk.org Tue Aug 2 17:32:43 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 2 Aug 2022 17:32:43 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 14:30:07 GMT, Axel Boldt-Christmas wrote: > @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) > > Description from the original issue: >> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >> >> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >> >> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. > > Testing: Tier 1-3 > Will run test tier 4-7 Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/9713 From sangheki at openjdk.org Tue Aug 2 17:33:54 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Tue, 2 Aug 2022 17:33:54 GMT Subject: RFR: 8290357: Drop HeapRegion::marked_bytes() In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 11:06:27 GMT, Thomas Schatzl wrote: > Hi all, > > please review this removal of the `HeapRegion::_marked_bytes` member that records the bytes marked below tams in the recent mark as it is not really interesting in the removed places. I added comments to give reasons for this removal in the particular places for your review. > > Testing: jtreg gc/g1, gha > > Thanks, > Thomas Looks good. Just minor nit regarding the remaining comment of _marked_bytes. ------------- Marked as reviewed by sangheki (Reviewer). PR: https://git.openjdk.org/jdk/pull/9511 From iklam at openjdk.org Tue Aug 2 17:56:07 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Aug 2022 17:56:07 GMT Subject: RFR: 8290840: Refactor the "os" class [v7] In-Reply-To: References: Message-ID: > Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. > > The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. > > This RFE tries to address the following: > > - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. > - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @stefank comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9600/files - new: https://git.openjdk.org/jdk/pull/9600/files/b6e60a54..11c3c3d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=05-06 Stats: 24 lines in 14 files changed: 11 ins; 13 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9600/head:pull/9600 PR: https://git.openjdk.org/jdk/pull/9600 From tschatzl at openjdk.org Tue Aug 2 18:00:20 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 2 Aug 2022 18:00:20 GMT Subject: RFR: 8290357: Drop HeapRegion::marked_bytes() [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this removal of the `HeapRegion::_marked_bytes` member that records the bytes marked below tams in the recent mark as it is not really interesting in the removed places. I added comments to give reasons for this removal in the particular places for your review. > > Testing: jtreg gc/g1, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Remove actual member and references ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9511/files - new: https://git.openjdk.org/jdk/pull/9511/files/9d7f95bb..f1c5bc5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9511&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9511&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9511.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9511/head:pull/9511 PR: https://git.openjdk.org/jdk/pull/9511 From shade at openjdk.org Tue Aug 2 18:17:23 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 2 Aug 2022 18:17:23 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null Message-ID: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL: static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS) NOT_MANAGEMENT_RETURN_(NULL); ``` I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses. Additional testing: - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0 - [ ] Linux x86_64 fastdebug server with GCC 9.3.0, `tier1` - [ ] Linux x86_64 fastdebug server with GCC 9.3.0, `tier2` - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability` ------------- Commit messages: - Drop comment - Fix Changes: https://git.openjdk.org/jdk/pull/9718/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9718&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289002 Stats: 11 lines in 3 files changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9718.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9718/head:pull/9718 PR: https://git.openjdk.org/jdk/pull/9718 From kvn at openjdk.org Tue Aug 2 19:56:45 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 2 Aug 2022 19:56:45 GMT Subject: RFR: 8283232: x86: Improve vector broadcast operations [v13] In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 13:48:07 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch improves the generation of broadcasting a scalar in several ways: >> >> - As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines. >> - Vector broadcasting should prefer rematerialising to spilling when register pressure is high. >> - Load vectors using the same kind (integral vs floating point) of instructions as that of the results to avoid potential data bypass delay >> >> With this patch, the result of the added benchmark, which performs some operations with a really high register pressure, on my machine with Intel i7-7700HQ (avx2) is as follow: >> >> Before After >> Benchmark Mode Cnt Score Error Score Error Units Gain >> SpiltReplicate.testDouble avgt 5 42.621 ? 0.598 38.771 ? 0.797 ns/op +9.03% >> SpiltReplicate.testFloat avgt 5 42.245 ? 1.464 38.603 ? 0.367 ns/op +8.62% >> SpiltReplicate.testInt avgt 5 20.581 ? 5.791 13.755 ? 0.375 ns/op +33.17% >> SpiltReplicate.testLong avgt 5 17.794 ? 4.781 13.663 ? 0.387 ns/op +23.22% >> >> As expected, the constant table sizes shrink significantly from 1024 bytes to 256 bytes for `long`/`double` and 128 bytes for `int`/`float` cases. >> >> This patch also removes some redundant code paths and renames some incorrectly named instructions. >> >> Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > add load_constant_vector Testing of version 12 passed. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/7832 From dlong at openjdk.org Tue Aug 2 21:02:52 2022 From: dlong at openjdk.org (Dean Long) Date: Tue, 2 Aug 2022 21:02:52 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings Now that you are building a separate list of nmethods to deoptimize, what protects that list from nmethods being recycled by other threads? Don't you need to hold the CodeCache_lock? ------------- PR: https://git.openjdk.org/jdk/pull/9655 From gziemski at openjdk.org Tue Aug 2 21:13:46 2022 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 2 Aug 2022 21:13:46 GMT Subject: RFR: 8290840: Refactor the "os" class [v3] In-Reply-To: <-wRbV7feLdw6g3Thx5dYZ419KBmQ60TalieMj7AecAA=.ff3d7140-e16e-49a3-bf64-b3f1f559c601@github.com> References: <-wRbV7feLdw6g3Thx5dYZ419KBmQ60TalieMj7AecAA=.ff3d7140-e16e-49a3-bf64-b3f1f559c601@github.com> Message-ID: On Tue, 2 Aug 2022 07:12:33 GMT, Thomas Stuefe wrote: >>> Very good work. Only small remarks/nitpickings. >>> >>> One question though, how does it work if I want to use an API implemented on a per-platform base in shared code? E.g. `zero_page_read_protected()`? I include `os.hpp` to get the definition, but how do I get the implementation? I have to include the platform-specific inline header too? Still with the OS_HEADER macro? >>> >>> Cheers, Thomas >> >> I think we should avoid creating non-portable os::xxx APIs and then call them from shared code. There were some calls to os::Posix::xxx from the shared code that I fixed in this PR. >> >> If you really want to make a platform-specific call, you should just do this (sadly we have many such cases) >> >> >> #ifdef LINUX >> linux_blah(); >> #endif >> >> >> Putting linux_blah() into the os class seems pointless. > >> >> I think we should avoid creating non-portable os::xxx APIs and then call them from shared code. There were some calls to os::Posix::xxx from the shared code that I fixed in this PR. > > I don't think that's what I meant. I meant APIs that exist for all OSes but have different expressions on each OS. So the prototype should live in shared os. But I want to pull a different implementation for each OS. > > This only affects inline functions. If the different implementations live in os_xx.cpp it works automatically through link time resolution. > > I see there are only a few examples for what I meant. Many inline functions return platform dependend values and those live in variables in shared code (e.g. os::vm_page_size(), ...). Others are just not inline (os.create_thread(), ...). Which leaves us with the likes of `zero_page_read_protected()` etc, and I see you put them into os.inline.hpp and there you include the OS specific headers too. > > I guess this can mostly be avoided. E.g. there is zero reason why `zero_page_read_protected()` cannot be a static boolean variable in os. For future RFEs. > @tstuefe @gerard-ziemski > > I've simplified `os::resolve_function_descriptor()` according to your suggestions, but I changed the #ifdefs to be more exact: > > ``` > // Used only on PPC for AIX, or LINUX (ppc but not ppcle). > static void* resolve_function_descriptor(void* p) > #if defined(PPC) && (defined(AIX) || (defined(LINUX) && !defined(ABI_ELFv2))) > ; > #else > { return NULL; } > #endif > ``` > > If we use "#if defined(PPC) && !defined(ABI_ELFv2)))" it would be very difficult to understand. > > To be honest, I am not a big fan of adding #ifdefs into os.hpp just to save a few lines of code. The #ifdefs are hard to understand. They are also fragile if you need to add a new platform that also support this functionality. > > I am (semi) OK with doing this for resolve_function_descriptor(), as that's a PPC-only thing that's unlikely to apply for other platforms. However, I don't want to use the same pattern for os::platform_print_native_stack() because we may want to implement this for other planforms. Thank you for trying. I am not completely happy about the new #ifdef and it doesn't look as clean to me as I imagined it would, so I am OK with you going with the original way it way. I guess, we could address it in a follow up if we come up with a nicer way of doing this... ------------- PR: https://git.openjdk.org/jdk/pull/9600 From gziemski at openjdk.org Tue Aug 2 21:18:43 2022 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 2 Aug 2022 21:18:43 GMT Subject: RFR: 8290840: Refactor the "os" class [v7] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 17:56:07 GMT, Ioi Lam wrote: >> Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. >> >> The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. >> >> This RFE tries to address the following: >> >> - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. >> - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @stefank comments Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/9600 From dlong at openjdk.org Tue Aug 2 21:33:41 2022 From: dlong at openjdk.org (Dean Long) Date: Tue, 2 Aug 2022 21:33:41 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading In-Reply-To: References: Message-ID: <5JfLyDDTi0H7WRva8W0WV7hI3xKvxVo7mPyaWzpx1pw=.a682010e-356f-4972-a343-a2058fa2b2ef@github.com> On Tue, 2 Aug 2022 14:30:07 GMT, Axel Boldt-Christmas wrote: > @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) > > Description from the original issue: >> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >> >> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >> >> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. > > Testing: Tier 1-3 > Will run test tier 4-7 src/hotspot/share/code/dependencyContext.cpp line 221: > 219: int removed = 0; > 220: while (b != NULL) { > 221: b = release_and_get_next_not_unloading(b); If we are being called by class unloading, finding an nmethod with nm->is_alive() returning true would be fatal, wouldn't it? Could we make it clear this function is used for unloading, and add an assert that !nm->is_alive() && nm->has_flushed_dependencies()? ------------- PR: https://git.openjdk.org/jdk/pull/9713 From amenkov at openjdk.org Tue Aug 2 22:03:06 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 2 Aug 2022 22:03:06 GMT Subject: RFR: 8290908: misc tests fail: assert(!thread->owns_locks()) failed: must release all locks when leaving VM In-Reply-To: References: Message-ID: <33PUVzpnb1IiVPy7U7CTIGr_cjAFn_Elj4uvoa3hw3Q=.40ee2a10-8dda-42ce-8054-1277b06588dc@github.com> On Mon, 1 Aug 2022 07:41:50 GMT, Serguei Spitsyn wrote: > This is a regression that has been introduced by the fix of: > [8256811](https://bugs.openjdk.org/browse/JDK-8256811): Delayed/missed jdwp class unloading events > > This is the relevant comment from Zhengyu: > > It is caused by https://bugs.openjdk.org/browse/JDK-8256811 as JvmtiExport::post_object_free() call does not expect under any lock. > > I think we can move following code outside of lock, as flush_obect_free_events() races ServiceThread's JvmtiTagMap::flush_all_object_free_events() call anyway. > > if (event_type == JVMTI_EVENT_OBJECT_FREE) { > flush_object_free_events(env); > } > > The fix is as was suggested by Zhengyu above. > I was not able to reproduce JCK and nsk.jvmti test failures mentioned in the bug report. > However, this fix should address the problem as it moves the call to `flush_object_free_events(env)` out of a critical section with a lock. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9699 From sspitsyn at openjdk.org Tue Aug 2 22:43:06 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 2 Aug 2022 22:43:06 GMT Subject: RFR: 8290908: misc tests fail: assert(!thread->owns_locks()) failed: must release all locks when leaving VM In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 07:41:50 GMT, Serguei Spitsyn wrote: > This is a regression that has been introduced by the fix of: > [8256811](https://bugs.openjdk.org/browse/JDK-8256811): Delayed/missed jdwp class unloading events > > This is the relevant comment from Zhengyu: > > It is caused by https://bugs.openjdk.org/browse/JDK-8256811 as JvmtiExport::post_object_free() call does not expect under any lock. > > I think we can move following code outside of lock, as flush_obect_free_events() races ServiceThread's JvmtiTagMap::flush_all_object_free_events() call anyway. > > if (event_type == JVMTI_EVENT_OBJECT_FREE) { > flush_object_free_events(env); > } > > The fix is as was suggested by Zhengyu above. > I was not able to reproduce JCK and nsk.jvmti test failures mentioned in the bug report. > However, this fix should address the problem as it moves the call to `flush_object_free_events(env)` out of a critical section with a lock. Chris and Alex, thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/9699 From sspitsyn at openjdk.org Tue Aug 2 22:44:31 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 2 Aug 2022 22:44:31 GMT Subject: Integrated: 8290908: misc tests fail: assert(!thread->owns_locks()) failed: must release all locks when leaving VM In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 07:41:50 GMT, Serguei Spitsyn wrote: > This is a regression that has been introduced by the fix of: > [8256811](https://bugs.openjdk.org/browse/JDK-8256811): Delayed/missed jdwp class unloading events > > This is the relevant comment from Zhengyu: > > It is caused by https://bugs.openjdk.org/browse/JDK-8256811 as JvmtiExport::post_object_free() call does not expect under any lock. > > I think we can move following code outside of lock, as flush_obect_free_events() races ServiceThread's JvmtiTagMap::flush_all_object_free_events() call anyway. > > if (event_type == JVMTI_EVENT_OBJECT_FREE) { > flush_object_free_events(env); > } > > The fix is as was suggested by Zhengyu above. > I was not able to reproduce JCK and nsk.jvmti test failures mentioned in the bug report. > However, this fix should address the problem as it moves the call to `flush_object_free_events(env)` out of a critical section with a lock. This pull request has now been integrated. Changeset: 0ae83410 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/0ae834105740f7cf73fe96be22e0f564ad29b18d Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod 8290908: misc tests fail: assert(!thread->owns_locks()) failed: must release all locks when leaving VM Reviewed-by: cjplummer, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/9699 From duke at openjdk.org Wed Aug 3 01:52:48 2022 From: duke at openjdk.org (duke) Date: Wed, 3 Aug 2022 01:52:48 GMT Subject: Withdrawn: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/8731 From iklam at openjdk.org Wed Aug 3 04:21:55 2022 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 3 Aug 2022 04:21:55 GMT Subject: RFR: 8290840: Refactor the "os" class [v8] In-Reply-To: References: Message-ID: > Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. > > The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. > > This RFE tries to address the following: > > - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. > - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Revert "simplified rarely-defined function os::resolve_function_descriptor()" This reverts commit 72efa9c0f81105d2f95e06e64e0123a8ac3a1745. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9600/files - new: https://git.openjdk.org/jdk/pull/9600/files/11c3c3d3..cf93fb74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=06-07 Stats: 36 lines in 8 files changed: 25 ins; 6 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9600/head:pull/9600 PR: https://git.openjdk.org/jdk/pull/9600 From iklam at openjdk.org Wed Aug 3 04:21:56 2022 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 3 Aug 2022 04:21:56 GMT Subject: RFR: 8290840: Refactor the "os" class [v3] In-Reply-To: <-wRbV7feLdw6g3Thx5dYZ419KBmQ60TalieMj7AecAA=.ff3d7140-e16e-49a3-bf64-b3f1f559c601@github.com> References: <-wRbV7feLdw6g3Thx5dYZ419KBmQ60TalieMj7AecAA=.ff3d7140-e16e-49a3-bf64-b3f1f559c601@github.com> Message-ID: On Tue, 2 Aug 2022 07:12:33 GMT, Thomas Stuefe wrote: >>> Very good work. Only small remarks/nitpickings. >>> >>> One question though, how does it work if I want to use an API implemented on a per-platform base in shared code? E.g. `zero_page_read_protected()`? I include `os.hpp` to get the definition, but how do I get the implementation? I have to include the platform-specific inline header too? Still with the OS_HEADER macro? >>> >>> Cheers, Thomas >> >> I think we should avoid creating non-portable os::xxx APIs and then call them from shared code. There were some calls to os::Posix::xxx from the shared code that I fixed in this PR. >> >> If you really want to make a platform-specific call, you should just do this (sadly we have many such cases) >> >> >> #ifdef LINUX >> linux_blah(); >> #endif >> >> >> Putting linux_blah() into the os class seems pointless. > >> >> I think we should avoid creating non-portable os::xxx APIs and then call them from shared code. There were some calls to os::Posix::xxx from the shared code that I fixed in this PR. > > I don't think that's what I meant. I meant APIs that exist for all OSes but have different expressions on each OS. So the prototype should live in shared os. But I want to pull a different implementation for each OS. > > This only affects inline functions. If the different implementations live in os_xx.cpp it works automatically through link time resolution. > > I see there are only a few examples for what I meant. Many inline functions return platform dependend values and those live in variables in shared code (e.g. os::vm_page_size(), ...). Others are just not inline (os.create_thread(), ...). Which leaves us with the likes of `zero_page_read_protected()` etc, and I see you put them into os.inline.hpp and there you include the OS specific headers too. > > I guess this can mostly be avoided. E.g. there is zero reason why `zero_page_read_protected()` cannot be a static boolean variable in os. For future RFEs. > > @tstuefe @gerard-ziemski > > I've simplified `os::resolve_function_descriptor()` according to your suggestions, but I changed the #ifdefs to be more exact: > > ``` > > // Used only on PPC for AIX, or LINUX (ppc but not ppcle). > > static void* resolve_function_descriptor(void* p) > > #if defined(PPC) && (defined(AIX) || (defined(LINUX) && !defined(ABI_ELFv2))) > > ; > > #else > > { return NULL; } > > #endif > > ``` > > > > > > > > > > > > > > > > > > > > > > > > If we use "#if defined(PPC) && !defined(ABI_ELFv2)))" it would be very difficult to understand. > > To be honest, I am not a big fan of adding #ifdefs into os.hpp just to save a few lines of code. The #ifdefs are hard to understand. They are also fragile if you need to add a new platform that also support this functionality. > > I am (semi) OK with doing this for resolve_function_descriptor(), as that's a PPC-only thing that's unlikely to apply for other platforms. However, I don't want to use the same pattern for os::platform_print_native_stack() because we may want to implement this for other planforms. > > Thank you for trying. I am not completely happy about the new #ifdef and it doesn't look as clean to me as I imagined it would, so I am OK with you going with the original way it way. I guess, we could address it in a follow up if we come up with a nicer way of doing this... Hi Gerard, thanks for the review. I've reverted the #ifdef change and gone back to the original way. See commit [cf93fb7](https://github.com/openjdk/jdk/pull/9600/commits/cf93fb743b15414f695b01649327759f57912290) ------------- PR: https://git.openjdk.org/jdk/pull/9600 From dholmes at openjdk.org Wed Aug 3 04:53:07 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Aug 2022 04:53:07 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null In-Reply-To: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: <3Mqtg0iqIoVQFH3VGBe64uAiANjE7SEBItDV4NqDQb8=.6d3183a8-848a-4c2a-8c9b-b19bb47a8f33@github.com> On Tue, 2 Aug 2022 18:11:33 GMT, Aleksey Shipilev wrote: > These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL: > > > static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS) > NOT_MANAGEMENT_RETURN_(NULL); > ``` > > I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses. > > Additional testing: > - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0 > - [ ] Linux x86_64 fastdebug server with GCC 9.3.0, `tier1` > - [ ] Linux x86_64 fastdebug server with GCC 9.3.0, `tier2` > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability` I can't help but feel that without INCLUDE_MANAGEMENT we should not be getting to the code concerned, so something seems amiss to me. But I don't have cycles at the moment to try and trace through this. ------------- PR: https://git.openjdk.org/jdk/pull/9718 From dholmes at openjdk.org Wed Aug 3 05:02:26 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Aug 2022 05:02:26 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null In-Reply-To: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: <9qOlOnvyetdBGJnd39b13XyjfcrhQzpGQADFP9j7fp4=.18bc5eec-f012-43bd-bf2c-2465fd349c98@github.com> On Tue, 2 Aug 2022 18:11:33 GMT, Aleksey Shipilev wrote: > These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL: > > > static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS) > NOT_MANAGEMENT_RETURN_(NULL); > ``` > > I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses. > > Additional testing: > - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0 > - [ ] Linux x86_64 fastdebug server with GCC 9.3.0, `tier1` > - [ ] Linux x86_64 fastdebug server with GCC 9.3.0, `tier2` > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability` Though it is also possible code changes have crept in that have not taken INCLUDE_MANAGEMENT into account. ------------- PR: https://git.openjdk.org/jdk/pull/9718 From iklam at openjdk.org Wed Aug 3 05:34:27 2022 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 3 Aug 2022 05:34:27 GMT Subject: RFR: 8290812: Add a test for ResourceHashtable [v7] In-Reply-To: References: Message-ID: <0jFlpVCqwJOxcuA_pP9c991d9HTXV3DidioVuw5lhuU=.132493f0-b8b3-4c9d-90b1-eda8a26f58cc@github.com> On Mon, 1 Aug 2022 22:17:30 GMT, Coleen Phillimore wrote: >> I added a test for ResourceHashtable to show the interactions with it and Symbol* refcounting. >> Tested with tier1 on Oracle platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Expand to 5 tests and one that's simple. test/hotspot/gtest/utilities/test_resourceHash.cpp line 363: > 361: } > 362: }; > 363: }; It's a bit challenging to read 5 consecutive test cases that are subtly different. Maybe SimpleDeleter should be moved to a separate class, like ResourceHashtableSimpleDeleteTest. Then we can separate the test cases into a group of 2 and another group of 3. test/hotspot/gtest/utilities/test_resourceHash.cpp line 429: > 427: _test_table.unlink(&deleter); > 428: ASSERT_EQ(d->refcount(), d_orig_count) << "refcount should be as we started"; > 429: } `value_delete` and `value_remove` use the exact same table instance. It's unclear from the example why `value_delete` needs to manipulate the key's refcount explicitly, but the latter doesn't. test/hotspot/gtest/utilities/test_resourceHash.cpp line 439: > 437: // refcount outside the hashtable functions. > 438: s->increment_refcount(); > 439: _ptr_test_table.put(s, tv); I am not sure why it's necessary to do s->increment_refcount() here and key->decrement_refcount() in PtrDeleter. We know that the symbol will be kept alive by the TestValue. These two inc/dec calls are done where we know that the TestValue is alive (after instantiation, and before deallocation). By removing these calls, we can reduce the chance of mishandling the refcount. ------------- PR: https://git.openjdk.org/jdk/pull/9603 From shade at openjdk.org Wed Aug 3 05:48:44 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Aug 2022 05:48:44 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null In-Reply-To: <9qOlOnvyetdBGJnd39b13XyjfcrhQzpGQADFP9j7fp4=.18bc5eec-f012-43bd-bf2c-2465fd349c98@github.com> References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> <9qOlOnvyetdBGJnd39b13XyjfcrhQzpGQADFP9j7fp4=.18bc5eec-f012-43bd-bf2c-2465fd349c98@github.com> Message-ID: On Wed, 3 Aug 2022 05:00:06 GMT, David Holmes wrote: > Though it is also possible code changes have crept in that have not taken INCLUDE_MANAGEMENT into account. My initial patch was going in that direction: protecting some paths with `INCLUDE_MANAGEMENT`, but it quickly gets to look intrusive, questionable and ugly for me. Returning/throwing on those paths is much cleaner. ------------- PR: https://git.openjdk.org/jdk/pull/9718 From stefank at openjdk.org Wed Aug 3 07:22:12 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 Aug 2022 07:22:12 GMT Subject: RFR: 8290840: Refactor the "os" class [v8] In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 04:21:55 GMT, Ioi Lam wrote: >> Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. >> >> The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. >> >> This RFE tries to address the following: >> >> - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. >> - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Revert "simplified rarely-defined function os::resolve_function_descriptor()" > > This reverts commit 72efa9c0f81105d2f95e06e64e0123a8ac3a1745. Three more nits, otherwise looks good. src/hotspot/os/bsd/os_bsd.inline.hpp line 29: > 27: > 28: #include "runtime/os.hpp" > 29: #include "os_bsd.hpp" Change to: #include "os_bsd.hpp" #include "runtime/os.hpp" src/hotspot/os/linux/os_linux.inline.hpp line 30: > 28: #include "runtime/os.hpp" > 29: #include "os_linux.hpp" > 30: #include "os_posix.inline.hpp" Change to: #include "os_linux.hpp" #include "runtime/os.hpp" #include "os_posix.inline.hpp" src/hotspot/os/windows/os_windows.inline.hpp line 32: > 30: #include "os_windows.hpp" > 31: #include "runtime/javaThread.hpp" > 32: #include "runtime/mutex.hpp" Change to: #include "os_windows.hpp" #include "runtime/javaThread.hpp" #include "runtime/mutex.hpp" ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.org/jdk/pull/9600 From shade at openjdk.org Wed Aug 3 08:19:46 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Aug 2022 08:19:46 GMT Subject: RFR: 8291633: Build failures with GCC 11, Alpine 3 due to incompatible casts from nullptr In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 17:01:51 GMT, Aleksey Shipilev wrote: > Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. > > They fall into three categories: > - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does; > - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it; > - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead. > > Additional testing: > - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15, GCC 11.2.1 > - [x] Linux x86_64 fastdebug tier1 with GCC 9.3.0 Thank you! If there are no other reviews, I'll be integrating this soon. ------------- PR: https://git.openjdk.org/jdk/pull/9705 From dholmes at openjdk.org Wed Aug 3 08:20:45 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Aug 2022 08:20:45 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null In-Reply-To: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: On Tue, 2 Aug 2022 18:11:33 GMT, Aleksey Shipilev wrote: > These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL: > > > static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS) > NOT_MANAGEMENT_RETURN_(NULL); > ``` > > I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses. > > Additional testing: > - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0 > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier1` > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier2` > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability` But the higher-level API's must be aware that management support may not exist and they should then be specified to behave a certain way when that is true. That specified behaviour may not be throwing your new exceptions. If the APIs do not account for the management interface not being available, then that is a significant bug that needs fixing. That said I have to refresh my memory as to whether the Minimal VM is only supported by certain compact profiles (which would exclude the high-level API's we are discussing). It may simply be an invalid configuration to have a Minimal VM but a full set of Java API's. ------------- PR: https://git.openjdk.org/jdk/pull/9718 From alanb at openjdk.org Wed Aug 3 08:39:38 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Aug 2022 08:39:38 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null In-Reply-To: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: On Tue, 2 Aug 2022 18:11:33 GMT, Aleksey Shipilev wrote: > These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL: > > > static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS) > NOT_MANAGEMENT_RETURN_(NULL); > ``` > > I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses. > > Additional testing: > - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0 > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier1` > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier2` > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability` The minimal VM build dates from the compact profiles defined in Java 8. The compact1 and compact2 profiles didn't have the j.l.management APIs so a minimal VM build of libjvm without the "management" code would have been okay. For Java 9+ then a minimal VM build without "management" only make sense when using jlink to create a run-time image that doesn't have the java.management module. ------------- PR: https://git.openjdk.org/jdk/pull/9718 From jiefu at openjdk.org Wed Aug 3 08:40:41 2022 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 3 Aug 2022 08:40:41 GMT Subject: RFR: 8291633: Build failures with GCC 11, Alpine 3 due to incompatible casts from nullptr In-Reply-To: References: Message-ID: <9DN64MNNW_KH8OKweTt8ZYJqI9GbA5YkEyQDoL-YR0U=.9b8a829b-fe4a-40f3-9014-2d45df0a7911@github.com> On Wed, 3 Aug 2022 08:15:56 GMT, Aleksey Shipilev wrote: > Thank you! If there are no other reviews, I'll be integrating this soon. Maybe, we'd better update the copyright year of src/hotspot/cpu/x86/interpreterRT_x86_64.cpp before integration. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9705 From shade at openjdk.org Wed Aug 3 08:50:08 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Aug 2022 08:50:08 GMT Subject: RFR: 8291633: Build failures with GCC 11, Alpine 3 due to incompatible casts from nullptr [v2] In-Reply-To: References: Message-ID: > Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. > > They fall into three categories: > - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does; > - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it; > - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead. > > Additional testing: > - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15, GCC 11.2.1 > - [x] Linux x86_64 fastdebug tier1 with GCC 9.3.0 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 four additional commits since the last revision: - Copyright years - Merge branch 'master' into JDK-8291633-alpine3-nullptr - More work - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9705/files - new: https://git.openjdk.org/jdk/pull/9705/files/59f92b41..3d3dbc3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9705&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9705&range=00-01 Stats: 1075 lines in 48 files changed: 648 ins; 260 del; 167 mod Patch: https://git.openjdk.org/jdk/pull/9705.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9705/head:pull/9705 PR: https://git.openjdk.org/jdk/pull/9705 From duke at openjdk.org Wed Aug 3 09:29:54 2022 From: duke at openjdk.org (Yi-Fan Tsai) Date: Wed, 3 Aug 2022 09:29:54 GMT Subject: RFR: 8280152: AArch64: Reuse runtime call trampolines [v4] In-Reply-To: <2yzoo-9v59f9D8mZuYQp9qL-ufvo3-0T1aKuGA65YQ4=.e33d044f-5f60-464e-b6b4-b06496a59f11@github.com> References: <2Rz88X0uWMdi7N4NFC36ZiMXgOhUmh0XehnaOKo6JWM=.9422ee14-4e73-47a5-a211-842fa5331391@github.com> <2yzoo-9v59f9D8mZuYQp9qL-ufvo3-0T1aKuGA65YQ4=.e33d044f-5f60-464e-b6b4-b06496a59f11@github.com> Message-ID: On Fri, 22 Jul 2022 08:17:56 GMT, Andrew Haley wrote: > it seems rather eccentric to create an array of all the calls, then create a hash table from the array. This approach has been replaced by open hashing. ------------- PR: https://git.openjdk.org/jdk/pull/9405 From dholmes at openjdk.org Wed Aug 3 09:39:08 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Aug 2022 09:39:08 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null In-Reply-To: References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: On Wed, 3 Aug 2022 08:36:37 GMT, Alan Bateman wrote: >> These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL: >> >> >> static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS) >> NOT_MANAGEMENT_RETURN_(NULL); >> ``` >> >> I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0 >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier1` >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier2` >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability` > > The minimal VM build dates from the compact profiles defined in Java 8. The compact1 and compact2 profiles didn't have the j.l.management APIs so a minimal VM build of libjvm without the "management" code would have been okay. For Java 9+ then a minimal VM build without "management" only make sense when using jlink to create a run-time image that doesn't have the java.management module. Thanks Alan (@AlanBateman )! That is what I was reaching for. I guess we lost the actual constraint when we moved to 9 that the Minimal VM cannot be used when the management module is present, as we presumably have no specification for how that module behaves in that case. Now that doesn't help in the current situation where GCC complains about a NULL this ptr as it cannot know about the fact this code should be unreachable in practice. I'm tempted to say we should use guarantees in the VM code and abort if we encounter the NULL - would that satisfy GCC? It seems better to fail fast and completely with such a misconfigured runtime environment. ------------- PR: https://git.openjdk.org/jdk/pull/9718 From tschatzl at openjdk.org Wed Aug 3 09:45:15 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 3 Aug 2022 09:45:15 GMT Subject: RFR: 8290357: Drop HeapRegion::marked_bytes() [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this removal of the `HeapRegion::_marked_bytes` member that records the bytes marked below tams in the recent mark as it is not really interesting in the removed places. I added comments to give reasons for this removal in the particular places for your review. > > Testing: jtreg gc/g1, gha > > Thanks, > Thomas Thomas Schatzl 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 8290357-remove-marked-bytes - Remove actual member and references - initial version, use live_bytes instead of marked_bytes ------------- Changes: https://git.openjdk.org/jdk/pull/9511/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9511&range=02 Stats: 52 lines in 8 files changed: 0 ins; 40 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9511.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9511/head:pull/9511 PR: https://git.openjdk.org/jdk/pull/9511 From shade at openjdk.org Wed Aug 3 11:02:41 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Aug 2022 11:02:41 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null In-Reply-To: References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: On Wed, 3 Aug 2022 09:34:43 GMT, David Holmes wrote: > Now that doesn't help in the current situation where GCC complains about a NULL this ptr as it cannot know about the fact this code should be unreachable in practice. I'm tempted to say we should use guarantees in the VM code and abort if we encounter the NULL - would that satisfy GCC? I tried to put `guarantee()`-s or conditional `fatal()` on those paths, and this still does not please GCC. I think it is the recurrent problem with those methods not marked as `noreturn` . So it works if we put the `return`-s as well. Like this: diff --git a/src/hotspot/share/services/diagnosticFramework.cpp b/src/hotspot/share/services/diagnosticFramework.cpp index 31ef9d0061b..944e161c321 100644 --- a/src/hotspot/share/services/diagnosticFramework.cpp +++ b/src/hotspot/share/services/diagnosticFramework.cpp @@ -462,6 +462,10 @@ void DCmdFactory::send_notification_internal(TRAPS) { if (notif) { Klass* k = Management::com_sun_management_internal_DiagnosticCommandImpl_klass(CHECK); + if (k == nullptr) { + fatal("Should have the class"); + return; + } InstanceKlass* dcmd_mbean_klass = InstanceKlass::cast(k); JavaValue result(T_OBJECT); diff --git a/src/hotspot/share/services/memoryManager.cpp b/src/hotspot/share/services/memoryManager.cpp index 38e308a8a15..d9527810e31 100644 --- a/src/hotspot/share/services/memoryManager.cpp +++ b/src/hotspot/share/services/memoryManager.cpp @@ -100,6 +100,11 @@ instanceOop MemoryManager::get_memory_manager_instance(TRAPS) { signature = vmSymbols::createMemoryManager_signature(); } + if (k == nullptr) { + fatal("Should have the class"); + return nullptr; + } + InstanceKlass* ik = InstanceKlass::cast(k); JavaCalls::call_static(&result, That would be okay with you, @dholmes-ora? ------------- PR: https://git.openjdk.org/jdk/pull/9718 From shade at openjdk.org Wed Aug 3 11:27:47 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Aug 2022 11:27:47 GMT Subject: RFR: 8291633: Build failures with GCC 11, Alpine 3 due to incompatible casts from nullptr In-Reply-To: <9DN64MNNW_KH8OKweTt8ZYJqI9GbA5YkEyQDoL-YR0U=.9b8a829b-fe4a-40f3-9014-2d45df0a7911@github.com> References: <9DN64MNNW_KH8OKweTt8ZYJqI9GbA5YkEyQDoL-YR0U=.9b8a829b-fe4a-40f3-9014-2d45df0a7911@github.com> Message-ID: On Wed, 3 Aug 2022 08:37:01 GMT, Jie Fu wrote: > Maybe, we'd better update the copyright year of src/hotspot/cpu/x86/interpreterRT_x86_64.cpp before integration. Thanks. Did so in new commit. ------------- PR: https://git.openjdk.org/jdk/pull/9705 From jiefu at openjdk.org Wed Aug 3 11:48:51 2022 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 3 Aug 2022 11:48:51 GMT Subject: RFR: 8291633: Build failures with GCC 11, Alpine 3 due to incompatible casts from nullptr [v2] In-Reply-To: References: Message-ID: <6XO_kN8TYlyxWqkcnMrTZGPkKGsLWmT5jBYVURF9AJg=.60c3a4a8-5d04-4556-9596-6f7cfc1a994d@github.com> On Wed, 3 Aug 2022 08:50:08 GMT, Aleksey Shipilev wrote: >> Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. >> >> They fall into three categories: >> - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does; >> - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it; >> - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead. >> >> Additional testing: >> - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15, GCC 11.2.1 >> - [x] Linux x86_64 fastdebug tier1 with GCC 9.3.0 > > 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 four additional commits since the last revision: > > - Copyright years > - Merge branch 'master' into JDK-8291633-alpine3-nullptr > - More work > - Fix Thanks for the update. LGTM ------------- Marked as reviewed by jiefu (Reviewer). PR: https://git.openjdk.org/jdk/pull/9705 From duke at openjdk.org Wed Aug 3 12:29:45 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Wed, 3 Aug 2022 12:29:45 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading In-Reply-To: <5JfLyDDTi0H7WRva8W0WV7hI3xKvxVo7mPyaWzpx1pw=.a682010e-356f-4972-a343-a2058fa2b2ef@github.com> References: <5JfLyDDTi0H7WRva8W0WV7hI3xKvxVo7mPyaWzpx1pw=.a682010e-356f-4972-a343-a2058fa2b2ef@github.com> Message-ID: On Tue, 2 Aug 2022 21:30:14 GMT, Dean Long wrote: >> @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) >> >> Description from the original issue: >>> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >>> >>> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >>> >>> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. >> >> Testing: Tier 1-3, 4-7 non-windows >> Windows tier 4-7 still queued > > src/hotspot/share/code/dependencyContext.cpp line 221: > >> 219: int removed = 0; >> 220: while (b != NULL) { >> 221: b = release_and_get_next_not_unloading(b); > > If we are being called by class unloading, finding an nmethod with nm->is_alive() returning true would be fatal, wouldn't it? Could we make it clear this function is used for unloading, and add an assert that !nm->is_alive() && nm->has_flushed_dependencies()? You are correct that nm should all be at least `unloading`, as if a klass is unloading all dependent `nmethods` should be unloading. So this code should boil down to: ```C++ void DependencyContext::remove_all_dependents() { nmethodBucket* b = dependencies_not_unloading(); set_dependencies(NULL); assert(b == nullptr, "All dependents should be unloading"); } As `dependencies_not_unloading()` will unlink and release every dependent that is `unloading`. Have run stress tests on that change and no violations were found. Will push and test this change. ------------- PR: https://git.openjdk.org/jdk/pull/9713 From duke at openjdk.org Wed Aug 3 12:31:53 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Wed, 3 Aug 2022 12:31:53 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v2] In-Reply-To: References: Message-ID: > @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) > > Description from the original issue: >> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >> >> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >> >> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. > > Testing: Tier 1-3, 4-7 non-windows > Windows tier 4-7 still queued Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Simplify and assert in remove_all_dependents ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9713/files - new: https://git.openjdk.org/jdk/pull/9713/files/6f86211c..0141b28d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9713.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9713/head:pull/9713 PR: https://git.openjdk.org/jdk/pull/9713 From duke at openjdk.org Wed Aug 3 12:54:12 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Wed, 3 Aug 2022 12:54:12 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v3] In-Reply-To: References: Message-ID: > @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) > > Description from the original issue: >> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >> >> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >> >> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. > > Testing: Tier 1-3, 4-7 non-windows > Windows tier 4-7 still queued Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Fix indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9713/files - new: https://git.openjdk.org/jdk/pull/9713/files/0141b28d..d94258d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=01-02 Stats: 19 lines in 1 file changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/9713.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9713/head:pull/9713 PR: https://git.openjdk.org/jdk/pull/9713 From coleenp at openjdk.org Wed Aug 3 13:10:07 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 3 Aug 2022 13:10:07 GMT Subject: Integrated: 8291733: Remove JFR events that expose hashtable In-Reply-To: <-M--ixe6ZniductAe4Xa9CfUZ_2-Ggy2RS80VeBvWaE=.0cf3d639-91b1-4b25-a519-f1ec55e857b8@github.com> References: <-M--ixe6ZniductAe4Xa9CfUZ_2-Ggy2RS80VeBvWaE=.0cf3d639-91b1-4b25-a519-f1ec55e857b8@github.com> Message-ID: On Tue, 2 Aug 2022 16:42:44 GMT, Coleen Phillimore wrote: > There are JFR events for the Placeholders table, LoaderConstraintTable and ProtectionDomainCacheTable. These events expose implementation details for these tables that we'd rather not expose. A users visibility into these tables will not be helpful and it restricts our ability to make these a different (smaller) table or in the case of ProtectionDomain, not a table at all. > > The Dictionary table (table of loaded classes) is useful from a users' perspective because it can be resized and we wanted to have events for the resizing. These other tables came along in that change. > > Tested with tier1-3. This pull request has now been integrated. Changeset: b7d2bde8 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/b7d2bde8e37817e827e685bd675b075c1f29b4c2 Stats: 113 lines in 8 files changed: 0 ins; 111 del; 2 mod 8291733: Remove JFR events that expose hashtable Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/9714 From marchof at openjdk.org Wed Aug 3 13:29:18 2022 From: marchof at openjdk.org (Marc R. Hoffmann) Date: Wed, 3 Aug 2022 13:29:18 GMT Subject: RFR: 8291822: ARM: fix build warnings with GCC11 Message-ID: Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 ------------- Commit messages: - 8291822: ARM: fix build warnings with GCC11 Changes: https://git.openjdk.org/jdk/pull/9727/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9727&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291822 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9727.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9727/head:pull/9727 PR: https://git.openjdk.org/jdk/pull/9727 From coleenp at openjdk.org Wed Aug 3 13:37:55 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 3 Aug 2022 13:37:55 GMT Subject: RFR: 8290812: Add a test for ResourceHashtable [v8] In-Reply-To: References: Message-ID: > I added a test for ResourceHashtable to show the interactions with it and Symbol* refcounting. > Tested with tier1 on Oracle platforms. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: More test cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9603/files - new: https://git.openjdk.org/jdk/pull/9603/files/9225844f..c2df44b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9603&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9603&range=06-07 Stats: 119 lines in 1 file changed: 51 ins; 53 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/9603.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9603/head:pull/9603 PR: https://git.openjdk.org/jdk/pull/9603 From coleenp at openjdk.org Wed Aug 3 13:37:58 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 3 Aug 2022 13:37:58 GMT Subject: RFR: 8290812: Add a test for ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 22:17:30 GMT, Coleen Phillimore wrote: >> I added a test for ResourceHashtable to show the interactions with it and Symbol* refcounting. >> Tested with tier1 on Oracle platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Expand to 5 tests and one that's simple. I'll do some more cleaning up, and hope the test makes more sense. Thanks Ioi. ------------- PR: https://git.openjdk.org/jdk/pull/9603 From coleenp at openjdk.org Wed Aug 3 13:38:03 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 3 Aug 2022 13:38:03 GMT Subject: RFR: 8290812: Add a test for ResourceHashtable [v7] In-Reply-To: <0jFlpVCqwJOxcuA_pP9c991d9HTXV3DidioVuw5lhuU=.132493f0-b8b3-4c9d-90b1-eda8a26f58cc@github.com> References: <0jFlpVCqwJOxcuA_pP9c991d9HTXV3DidioVuw5lhuU=.132493f0-b8b3-4c9d-90b1-eda8a26f58cc@github.com> Message-ID: On Wed, 3 Aug 2022 05:15:42 GMT, Ioi Lam wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Expand to 5 tests and one that's simple. > > test/hotspot/gtest/utilities/test_resourceHash.cpp line 363: > >> 361: } >> 362: }; >> 363: }; > > It's a bit challenging to read 5 consecutive test cases that are subtly different. Maybe SimpleDeleter should be moved to a separate class, like ResourceHashtableSimpleDeleteTest. Then we can separate the test cases into a group of 2 and another group of 3. I could do more splitting. > test/hotspot/gtest/utilities/test_resourceHash.cpp line 429: > >> 427: _test_table.unlink(&deleter); >> 428: ASSERT_EQ(d->refcount(), d_orig_count) << "refcount should be as we started"; >> 429: } > > `value_delete` and `value_remove` use the exact same table instance. It's unclear from the example why `value_delete` needs to manipulate the key's refcount explicitly, but the latter doesn't. I was trying to say it's not strictly necessary. When you have a remove function, you have a chance to delete the refcount outside the hashtable, but you have to do it in the do_entry function if you use unlink. I'll try to make the test clearer. I guess my comments are more ruminations rather than helpful. > test/hotspot/gtest/utilities/test_resourceHash.cpp line 439: > >> 437: // refcount outside the hashtable functions. >> 438: s->increment_refcount(); >> 439: _ptr_test_table.put(s, tv); > > I am not sure why it's necessary to do s->increment_refcount() here and key->decrement_refcount() in PtrDeleter. We know that the symbol will be kept alive by the TestValue. These two inc/dec calls are done where we know that the TestValue is alive (after instantiation, and before deallocation). By removing these calls, we can reduce the chance of mishandling the refcount. Yes, I was trying to show that you may have to manipulate the refcount in the Key if it's not kept alive by being the same in the Value. In this case it is. Adding the SimpleDeleter to show that does a better job of that though. ------------- PR: https://git.openjdk.org/jdk/pull/9603 From duke at openjdk.org Wed Aug 3 13:39:43 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Wed, 3 Aug 2022 13:39:43 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings As my previous comment will probably back out the linked list of this PR and create a separate issue that depends on this encapsulation that only deal with swapping to a linked list instead of walking the whole code cache. But as it will be based on this code your question is still relevant. I am pretty new to the codebase so please correct me if I am wrong, especially with regards to different locks, their scope and usage. Here is my understanding of why the linked list is valid as is. While working with the list we have a few things which are true: * `assert_locked_or_safepoint(Compile_lock);` anywhere were we modify the list, * once something is linked it cannot be linked again, as it is only linked if it is `not_marked` and the status can only go `not_marked -> deoptimize | deoptimize_noupdate -> deoptimize_done`. * `assert(extract_compiled_method(_mark_link) == nullptr, ...)` for some extra sanity around this * While the `MarkForDeoptimizationStatus` value makes linking something already linked impossible the assert above is not enough to catch if a tail of the list is linked in creating a cycle. Can either add an assert that walks the list and checks that the `tail != this`, or the `next_marked()` code can be changed to `take_next_marked()` which sets the field to `nullptr` and thus breaks any cycles when iterating (avoids infinite loops). The second would be alright as creating a loop from the tail to the root will never drop parts of the list, even if more elements are added after the cycle is created, as the `assert(extract_compiled_method(_mark_link) == nullptr, ...)` assert that the list will not break. * From the creation of a `DeoptimizationContext` to until the linked list has been processed (`make_not_entrant` and `make_deoptimized`) we have `NoSafepointVerifier` (which is the time to safe point issue this change is trying to address) * And this active part of the DeoptimizationContext cannot overlap with another active part of another DeoptimizationContext, checked via a bool flag. Maybe it is not correct to have a non volatile static bool here, but I though `assert_locked_or_safepoint(Compile_lock);` would be enough to guarantee synchronisation. But should probably change to load acquire atomics. I think most of the terminology will change to make it more deoptimization specific. Having it called `not_marked`, `_root_mark_link`, `_mark_link`, `next_mark()` and `take_root()` is to general and can lead to confusion. Another reason to split this out to a separate issue. Also using some other terminology than `mark` could be used. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From marchof at openjdk.org Wed Aug 3 13:40:06 2022 From: marchof at openjdk.org (Marc R. Hoffmann) Date: Wed, 3 Aug 2022 13:40:06 GMT Subject: RFR: 8291822: ARM: fix build warnings with GCC11 In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 12:49:01 GMT, Marc R. Hoffmann wrote: > Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 @tstuefe As discussed: Here is the PR to suppress gcc 11 compiler warnings for arm32 ------------- PR: https://git.openjdk.org/jdk/pull/9727 From duke at openjdk.org Wed Aug 3 13:45:42 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Wed, 3 Aug 2022 13:45:42 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v3] In-Reply-To: References: <5JfLyDDTi0H7WRva8W0WV7hI3xKvxVo7mPyaWzpx1pw=.a682010e-356f-4972-a343-a2058fa2b2ef@github.com> Message-ID: On Wed, 3 Aug 2022 12:25:56 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/code/dependencyContext.cpp line 221: >> >>> 219: int removed = 0; >>> 220: while (b != NULL) { >>> 221: b = release_and_get_next_not_unloading(b); >> >> If we are being called by class unloading, finding an nmethod with nm->is_alive() returning true would be fatal, wouldn't it? Could we make it clear this function is used for unloading, and add an assert that !nm->is_alive() && nm->has_flushed_dependencies()? > > You are correct that nm should all be at least `unloading`, as if a klass is unloading all dependent `nmethods` should be unloading. So this code should boil down to: > ```C++ > void DependencyContext::remove_all_dependents() { > nmethodBucket* b = dependencies_not_unloading(); > set_dependencies(NULL); > assert(b == nullptr, "All dependents should be unloading"); > } > > As `dependencies_not_unloading()` will unlink and release every dependent that is `unloading`. > Have run stress tests on that change and no violations were found. > Will push and test this change. > You are correct that nm should all be at least `unloading`, as if a klass is unloading all dependent `nmethods` should be unloading. So this code should boil down to: > > ```c++ > void DependencyContext::remove_all_dependents() { > nmethodBucket* b = dependencies_not_unloading(); > set_dependencies(NULL); > assert(b == nullptr, "All dependents should be unloading"); > } > ``` > > As `dependencies_not_unloading()` will unlink and release every dependent that is `unloading`. Have run stress tests on that change and no violations were found. Will push and test this change. >From testing this seems not to be the case. Will investigate some more. So there are dependents that do no become `unloading` when the klass unloads. ------------- PR: https://git.openjdk.org/jdk/pull/9713 From shade at openjdk.org Wed Aug 3 13:46:41 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Aug 2022 13:46:41 GMT Subject: RFR: 8291822: ARM: fix build warnings with GCC11 In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 12:49:01 GMT, Marc R. Hoffmann wrote: > Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 Looks okay, but see how other platforms do it, and do it similarly? https://github.com/openjdk/jdk/blob/b7d2bde8e37817e827e685bd675b075c1f29b4c2/src/hotspot/cpu/x86/frame_x86.inline.hpp#L327-L341 ------------- PR: https://git.openjdk.org/jdk/pull/9727 From duke at openjdk.org Wed Aug 3 13:55:59 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Wed, 3 Aug 2022 13:55:59 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v4] In-Reply-To: References: Message-ID: > @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) > > Description from the original issue: >> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >> >> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >> >> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. > > Testing: Tier 1-3, 4-7 non-windows > Windows tier 4-7 still queued Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: - Fix indentation - Revert "Simplify and assert in remove_all_dependents" This reverts commit 0141b28d3b30745da31e12a4489ac71e14bd18e2. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9713/files - new: https://git.openjdk.org/jdk/pull/9713/files/d94258d0..048f2f71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=02-03 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9713.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9713/head:pull/9713 PR: https://git.openjdk.org/jdk/pull/9713 From marchof at openjdk.org Wed Aug 3 13:57:43 2022 From: marchof at openjdk.org (Marc R. Hoffmann) Date: Wed, 3 Aug 2022 13:57:43 GMT Subject: RFR: 8291822: ARM: fix build warnings with GCC11 In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 13:43:11 GMT, Aleksey Shipilev wrote: >> Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 > > Looks okay, but see how other platforms do it, and do it similarly? https://github.com/openjdk/jdk/blob/b7d2bde8e37817e827e685bd675b075c1f29b4c2/src/hotspot/cpu/x86/frame_x86.inline.hpp#L327-L341 @shipilev Thanks for picking this up! I followed the AArch64 approach as I personally prefer to keep the scope for ignored warnings as small as possible. Just let me know what your preferred version is (beside fixing the root cause, this is beyond my c++ skills ?). https://github.com/openjdk/jdk/blob/b7d2bde8e37817e827e685bd675b075c1f29b4c2/src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp#L338-L355 ------------- PR: https://git.openjdk.org/jdk/pull/9727 From shade at openjdk.org Wed Aug 3 14:06:39 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Aug 2022 14:06:39 GMT Subject: RFR: 8291822: ARM: fix build warnings with GCC11 In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 12:49:01 GMT, Marc R. Hoffmann wrote: > Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 > I followed the AArch64 approach as I personally prefer to keep the scope for ignored warnings as small as possible. Just let me know what your preferred version is (beside fixing the root cause, this is beyond my c++ skills wink). My experience is that sometimes compilers get picky when pragmas are in the middle of the method (targeting single statements), so I'd prefer the way x86 does it. ------------- PR: https://git.openjdk.org/jdk/pull/9727 From marchof at openjdk.org Wed Aug 3 14:10:39 2022 From: marchof at openjdk.org (Marc R. Hoffmann) Date: Wed, 3 Aug 2022 14:10:39 GMT Subject: RFR: 8291822: ARM: fix build warnings with GCC11 In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 14:04:35 GMT, Aleksey Shipilev wrote: >> Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 > >> I followed the AArch64 approach as I personally prefer to keep the scope for ignored warnings as small as possible. Just let me know what your preferred version is (beside fixing the root cause, this is beyond my c++ skills wink). > > My experience is that sometimes compilers get picky when pragmas are in the middle of the method (targeting single statements), so I'd prefer the way x86 does it. @shipilev Should I adjust aarch64 accordingly or does this require a separate issue? ------------- PR: https://git.openjdk.org/jdk/pull/9727 From shade at openjdk.org Wed Aug 3 14:14:40 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Aug 2022 14:14:40 GMT Subject: RFR: 8291822: ARM: fix build warnings with GCC11 In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 14:04:35 GMT, Aleksey Shipilev wrote: >> Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 > >> I followed the AArch64 approach as I personally prefer to keep the scope for ignored warnings as small as possible. Just let me know what your preferred version is (beside fixing the root cause, this is beyond my c++ skills wink). > > My experience is that sometimes compilers get picky when pragmas are in the middle of the method (targeting single statements), so I'd prefer the way x86 does it. > @shipilev Should I adjust aarch64 accordingly or does this require a separate issue? No need, that aarch64 pragma block should go away eventually. Unless that poses an immediate problem (= there is a compiler that complains), there is no reason to change it. ------------- PR: https://git.openjdk.org/jdk/pull/9727 From marchof at openjdk.org Wed Aug 3 14:28:55 2022 From: marchof at openjdk.org (Marc R. Hoffmann) Date: Wed, 3 Aug 2022 14:28:55 GMT Subject: RFR: 8291822: ARM: fix build warnings with GCC11 [v2] In-Reply-To: References: Message-ID: > Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 Marc R. Hoffmann 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: 8291822: ARM: fix build warnings with GCC11 Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9727/files - new: https://git.openjdk.org/jdk/pull/9727/files/55266408..686e5507 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9727&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9727&range=00-01 Stats: 11 lines in 1 file changed: 5 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9727.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9727/head:pull/9727 PR: https://git.openjdk.org/jdk/pull/9727 From shade at openjdk.org Wed Aug 3 14:28:56 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Aug 2022 14:28:56 GMT Subject: RFR: 8291822: ARM: fix build warnings with GCC11 [v2] In-Reply-To: References: Message-ID: <_zeDp9_L0qwSQPd9mZH7doibtQNC6J9IqUYbvnco4Cw=.4b3397b7-1631-408b-a981-d802d26fd75e@github.com> On Wed, 3 Aug 2022 14:25:24 GMT, Marc R. Hoffmann wrote: >> Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 > > Marc R. Hoffmann 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: > > 8291822: ARM: fix build warnings with GCC11 > > Same workaround was applied for other platforms in > JDK-8270083 and JDK-8271869 Looks good, assuming ARM32 builds pass. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9727 From shade at openjdk.org Wed Aug 3 14:28:57 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Aug 2022 14:28:57 GMT Subject: RFR: 8291822: ARM: fix build warnings with GCC11 In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 12:49:01 GMT, Marc R. Hoffmann wrote: > Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 I also changed the bug title to something more aligned with the usual style for these kind of changes. Bots would soon complain that your PR needs to be renamed accordingly :) ------------- PR: https://git.openjdk.org/jdk/pull/9727 From marchof at openjdk.org Wed Aug 3 14:32:40 2022 From: marchof at openjdk.org (Marc R. Hoffmann) Date: Wed, 3 Aug 2022 14:32:40 GMT Subject: RFR: 8291822: ARM: fix build warnings with GCC11 [v3] In-Reply-To: References: Message-ID: > Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 Marc R. Hoffmann 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: 8291822: ARM32: Build errors with GCC 11 in frame::saved_oop_result Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9727/files - new: https://git.openjdk.org/jdk/pull/9727/files/686e5507..5596ea10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9727&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9727&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9727.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9727/head:pull/9727 PR: https://git.openjdk.org/jdk/pull/9727 From stuefe at openjdk.org Wed Aug 3 14:39:45 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 3 Aug 2022 14:39:45 GMT Subject: RFR: 8291822: ARM32: Build errors with GCC 11 in frame::saved_oop_result [v3] In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 14:32:40 GMT, Marc R. Hoffmann wrote: >> Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 > > Marc R. Hoffmann 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: > > 8291822: ARM32: Build errors with GCC 11 in frame::saved_oop_result > > Same workaround was applied for other platforms in > JDK-8270083 and JDK-8271869 Looks good. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/9727 From marchof at openjdk.org Wed Aug 3 16:35:56 2022 From: marchof at openjdk.org (Marc R. Hoffmann) Date: Wed, 3 Aug 2022 16:35:56 GMT Subject: RFR: 8291822: ARM32: Build errors with GCC 11 in frame::saved_oop_result [v3] In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 14:32:40 GMT, Marc R. Hoffmann wrote: >> Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 > > Marc R. Hoffmann 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: > > 8291822: ARM32: Build errors with GCC 11 in frame::saved_oop_result > > Same workaround was applied for other platforms in > JDK-8270083 and JDK-8271869 My ARM32 build is green and does not show the warning any more. ------------- PR: https://git.openjdk.org/jdk/pull/9727 From thomas.stuefe at gmail.com Wed Aug 3 17:21:39 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 3 Aug 2022 19:21:39 +0200 Subject: RFR: 8291822: ARM32: Build errors with GCC 11 in frame::saved_oop_result [v3] In-Reply-To: References: Message-ID: Great. I see Alexey already sponsored. Thanks for the fix! ..Thomas On Wed 3. Aug 2022 at 18:36, Marc R. Hoffmann wrote: > On Wed, 3 Aug 2022 14:32:40 GMT, Marc R. Hoffmann > wrote: > > >> Same workaround was applied for other platforms in JDK-8270083 and > JDK-8271869 > > > > Marc R. Hoffmann 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: > > > > 8291822: ARM32: Build errors with GCC 11 in frame::saved_oop_result > > > > Same workaround was applied for other platforms in > > JDK-8270083 and JDK-8271869 > > My ARM32 build is green and does not show the warning any more. > > ------------- > > PR: https://git.openjdk.org/jdk/pull/9727 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at openjdk.org Wed Aug 3 17:26:08 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Aug 2022 17:26:08 GMT Subject: RFR: 8291822: ARM32: Build errors with GCC 11 in frame::saved_oop_result [v3] In-Reply-To: References: Message-ID: <7aV3znwkPzFMvmu8Hozh-83nTCZa4PLiTTAnboPiuPQ=.5c6f2995-5560-4843-b32c-42b930c9661b@github.com> On Wed, 3 Aug 2022 14:32:40 GMT, Marc R. Hoffmann wrote: >> Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 > > Marc R. Hoffmann 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: > > 8291822: ARM32: Build errors with GCC 11 in frame::saved_oop_result > > Same workaround was applied for other platforms in > JDK-8270083 and JDK-8271869 GHA ARM32 build is also green. I think this patch is trivial, so we can integrate it now. ------------- PR: https://git.openjdk.org/jdk/pull/9727 From marchof at openjdk.org Wed Aug 3 17:26:13 2022 From: marchof at openjdk.org (Marc R. Hoffmann) Date: Wed, 3 Aug 2022 17:26:13 GMT Subject: Integrated: 8291822: ARM32: Build errors with GCC 11 in frame::saved_oop_result In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 12:49:01 GMT, Marc R. Hoffmann wrote: > Same workaround was applied for other platforms in JDK-8270083 and JDK-8271869 This pull request has now been integrated. Changeset: 4d6e6f67 Author: Marc R. Hoffmann Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/4d6e6f6741170a7f083a84e3e9f4b5f67099a433 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8291822: ARM32: Build errors with GCC 11 in frame::saved_oop_result Reviewed-by: shade, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/9727 From shade at openjdk.org Wed Aug 3 17:26:34 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Aug 2022 17:26:34 GMT Subject: Integrated: 8291633: Build failures with GCC 11, Alpine 3 due to incompatible casts from nullptr In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 17:01:51 GMT, Aleksey Shipilev wrote: > Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. > > They fall into three categories: > - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does; > - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it; > - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead. > > Additional testing: > - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15, GCC 11.2.1 > - [x] Linux x86_64 fastdebug tier1 with GCC 9.3.0 This pull request has now been integrated. Changeset: c89556f6 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/c89556f6cd4d0b64f3e9e2f1dc7c51634522f205 Stats: 16 lines in 6 files changed: 0 ins; 0 del; 16 mod 8291633: Build failures with GCC 11, Alpine 3 due to incompatible casts from nullptr Reviewed-by: stuefe, mbaesken, jiefu ------------- PR: https://git.openjdk.org/jdk/pull/9705 From shade at openjdk.org Wed Aug 3 18:39:19 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Aug 2022 18:39:19 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null [v2] In-Reply-To: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: > These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL: > > > static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS) > NOT_MANAGEMENT_RETURN_(NULL); > ``` > > I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses. > > Additional testing: > - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0 > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier1` > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier2` > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Cleaner fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9718/files - new: https://git.openjdk.org/jdk/pull/9718/files/aceebea1..5e0ed005 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9718&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9718&range=00-01 Stats: 7 lines in 3 files changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9718.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9718/head:pull/9718 PR: https://git.openjdk.org/jdk/pull/9718 From dlong at openjdk.org Wed Aug 3 19:37:40 2022 From: dlong at openjdk.org (Dean Long) Date: Wed, 3 Aug 2022 19:37:40 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings It's nmethod::flush() I'm worried about. It uses CodeCache_lock, not Compile_lock. It calls CodeCache::free() to destroy the nmethod. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From iklam at openjdk.org Wed Aug 3 20:07:43 2022 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 3 Aug 2022 20:07:43 GMT Subject: RFR: 8290812: Add a test for ResourceHashtable [v8] In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 13:37:55 GMT, Coleen Phillimore wrote: >> I added a test for ResourceHashtable to show the interactions with it and Symbol* refcounting. >> Tested with tier1 on Oracle platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > More test cleanup The new version looks good to me. Thanks for being patient with my comments :-) ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/9603 From iklam at openjdk.org Wed Aug 3 20:11:16 2022 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 3 Aug 2022 20:11:16 GMT Subject: RFR: 8290840: Refactor the "os" class [v9] In-Reply-To: References: Message-ID: > Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. > > The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. > > This RFE tries to address the following: > > - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. > - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed more inline.hpp #include order ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9600/files - new: https://git.openjdk.org/jdk/pull/9600/files/cf93fb74..8ed25f4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=07-08 Stats: 11 lines in 5 files changed: 5 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9600/head:pull/9600 PR: https://git.openjdk.org/jdk/pull/9600 From eosterlund at openjdk.org Wed Aug 3 20:39:34 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 3 Aug 2022 20:39:34 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings The nmethods we link together are is_alive. There is also no safepoint. It would be impossible for such nmethods to be flushed without a safepoint. It could racingly flip to zombie, but it would need yet another thread-local handshake from the sweeper for it to flush the nmethods. That can not happen without safepoints in this code path. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From eosterlund at openjdk.org Wed Aug 3 20:45:22 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 3 Aug 2022 20:45:22 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings Also, in DeoptimizationContext::deopt_compiled_methods, the SweeperBlocker completely blocks out the sweeper from running. But as I mentioned, even without that, without safepoint checks, we can never flush these things. It's worth mentioning that there used to be a special case for OSR nmethods that they could be flushed immediately and skip the zombie step. But I removed that a few tears ago so we wouldn't have to think about that pathological case separately. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From iklam at openjdk.org Thu Aug 4 01:19:37 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Aug 2022 01:19:37 GMT Subject: RFR: 8290840: Refactor the "os" class [v10] In-Reply-To: References: Message-ID: > Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. > > The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. > > This RFE tries to address the following: > > - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. > - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. 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 17 additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into 8290840-refactor-the-os-class - fixed more inline.hpp #include order - Revert "simplified rarely-defined function os::resolve_function_descriptor()" This reverts commit 72efa9c0f81105d2f95e06e64e0123a8ac3a1745. - @stefank comments - clarified comments about inline functions declared in os.hpp - Merge branch 'master' into 8290840-refactor-the-os-class - made workaround_expand_exec_shield_cs_limit() static; added PPC comments for os::resolve_function_descriptor() - fixed whitespace - clarify comment - PLATFORM_PRINT_NATIVE_STACK -> HAVE_PLATFORM_PRINT_NATIVE_STACK - ... and 7 more: https://git.openjdk.org/jdk/compare/ea1ca6a2...7764c9e4 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9600/files - new: https://git.openjdk.org/jdk/pull/9600/files/8ed25f4e..7764c9e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9600&range=08-09 Stats: 759 lines in 80 files changed: 311 ins; 344 del; 104 mod Patch: https://git.openjdk.org/jdk/pull/9600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9600/head:pull/9600 PR: https://git.openjdk.org/jdk/pull/9600 From iklam at openjdk.org Thu Aug 4 01:19:37 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Aug 2022 01:19:37 GMT Subject: RFR: 8290840: Refactor the "os" class [v3] In-Reply-To: <-wRbV7feLdw6g3Thx5dYZ419KBmQ60TalieMj7AecAA=.ff3d7140-e16e-49a3-bf64-b3f1f559c601@github.com> References: <-wRbV7feLdw6g3Thx5dYZ419KBmQ60TalieMj7AecAA=.ff3d7140-e16e-49a3-bf64-b3f1f559c601@github.com> Message-ID: On Tue, 2 Aug 2022 07:12:33 GMT, Thomas Stuefe wrote: >>> Very good work. Only small remarks/nitpickings. >>> >>> One question though, how does it work if I want to use an API implemented on a per-platform base in shared code? E.g. `zero_page_read_protected()`? I include `os.hpp` to get the definition, but how do I get the implementation? I have to include the platform-specific inline header too? Still with the OS_HEADER macro? >>> >>> Cheers, Thomas >> >> I think we should avoid creating non-portable os::xxx APIs and then call them from shared code. There were some calls to os::Posix::xxx from the shared code that I fixed in this PR. >> >> If you really want to make a platform-specific call, you should just do this (sadly we have many such cases) >> >> >> #ifdef LINUX >> linux_blah(); >> #endif >> >> >> Putting linux_blah() into the os class seems pointless. > >> >> I think we should avoid creating non-portable os::xxx APIs and then call them from shared code. There were some calls to os::Posix::xxx from the shared code that I fixed in this PR. > > I don't think that's what I meant. I meant APIs that exist for all OSes but have different expressions on each OS. So the prototype should live in shared os. But I want to pull a different implementation for each OS. > > This only affects inline functions. If the different implementations live in os_xx.cpp it works automatically through link time resolution. > > I see there are only a few examples for what I meant. Many inline functions return platform dependend values and those live in variables in shared code (e.g. os::vm_page_size(), ...). Others are just not inline (os.create_thread(), ...). Which leaves us with the likes of `zero_page_read_protected()` etc, and I see you put them into os.inline.hpp and there you include the OS specific headers too. > > I guess this can mostly be avoided. E.g. there is zero reason why `zero_page_read_protected()` cannot be a static boolean variable in os. For future RFEs. Thanks @tstuefe @gerard-ziemski @stefank @dholmes-ora for the review. Passed build tiers 1 and 5. ------------- PR: https://git.openjdk.org/jdk/pull/9600 From iklam at openjdk.org Thu Aug 4 01:24:17 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Aug 2022 01:24:17 GMT Subject: Integrated: 8290840: Refactor the "os" class In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 19:45:13 GMT, Ioi Lam wrote: > Please see [JDK-8290840](https://bugs.openjdk.org/browse/JDK-8290840) for the detailed proposal. > > The `os` class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added. > > This RFE tries to address the following: > > - Clearly specify where a porting API should be declared and defined among the various `os*.cpp` and `os*.hpp` files. > - Avoid the inappropriate inclusion of OS-specific APIs (such as the `os::Linux class`) by platform-independent source files. This pull request has now been integrated. Changeset: b6b0317f Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/b6b0317f832985470ccf4bc1e2abf9015ce5bd54 Stats: 1463 lines in 94 files changed: 692 ins; 683 del; 88 mod 8290840: Refactor the "os" class Reviewed-by: dholmes, gziemski, stuefe, stefank ------------- PR: https://git.openjdk.org/jdk/pull/9600 From duke at openjdk.org Thu Aug 4 06:07:05 2022 From: duke at openjdk.org (duke) Date: Thu, 4 Aug 2022 06:07:05 GMT Subject: Withdrawn: 8285149: Using HashMap.newHashMap to replace new HashMap(int) In-Reply-To: References: Message-ID: <6zyYs300tD4dVrr_FT6ILURyaxkXaKtDe3rbLm1rMD8=.64484460-e180-4b3b-97f9-8573daa11da0@github.com> On Tue, 19 Apr 2022 17:44:10 GMT, XenoAmess wrote: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/8301 From duke at openjdk.org Thu Aug 4 07:41:15 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Thu, 4 Aug 2022 07:41:15 GMT Subject: RFR: 8283232: x86: Improve vector broadcast operations [v13] In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 13:48:07 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch improves the generation of broadcasting a scalar in several ways: >> >> - As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines. >> - Vector broadcasting should prefer rematerialising to spilling when register pressure is high. >> - Load vectors using the same kind (integral vs floating point) of instructions as that of the results to avoid potential data bypass delay >> >> With this patch, the result of the added benchmark, which performs some operations with a really high register pressure, on my machine with Intel i7-7700HQ (avx2) is as follow: >> >> Before After >> Benchmark Mode Cnt Score Error Score Error Units Gain >> SpiltReplicate.testDouble avgt 5 42.621 ? 0.598 38.771 ? 0.797 ns/op +9.03% >> SpiltReplicate.testFloat avgt 5 42.245 ? 1.464 38.603 ? 0.367 ns/op +8.62% >> SpiltReplicate.testInt avgt 5 20.581 ? 5.791 13.755 ? 0.375 ns/op +33.17% >> SpiltReplicate.testLong avgt 5 17.794 ? 4.781 13.663 ? 0.387 ns/op +23.22% >> >> As expected, the constant table sizes shrink significantly from 1024 bytes to 256 bytes for `long`/`double` and 128 bytes for `int`/`float` cases. >> >> This patch also removes some redundant code paths and renames some incorrectly named instructions. >> >> Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > add load_constant_vector May I have this PR sponsored, please? Thanks a lot for your help. ------------- PR: https://git.openjdk.org/jdk/pull/7832 From alanb at openjdk.org Thu Aug 4 07:44:55 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 4 Aug 2022 07:44:55 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null In-Reply-To: References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: On Wed, 3 Aug 2022 08:36:37 GMT, Alan Bateman wrote: >> These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL: >> >> >> static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS) >> NOT_MANAGEMENT_RETURN_(NULL); >> ``` >> >> I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0 >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier1` >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier2` >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability` > > The minimal VM build dates from the compact profiles defined in Java 8. The compact1 and compact2 profiles didn't have the j.l.management APIs so a minimal VM build of libjvm without the "management" code would have been okay. For Java 9+ then a minimal VM build without "management" only make sense when using jlink to create a run-time image that doesn't have the java.management module. > Thanks Alan (@AlanBateman )! That is what I was reaching for. I guess we lost the actual constraint when we moved to 9 that the Minimal VM cannot be used when the management module is present, as we presumably have no specification for how that module behaves in that case. There wasn't any real constraint in JDK 8 either, it was just that the minimal VM build was for compact1 and compact2. It's a topic that I discussed a few times with Bob Vandette but it never rose to the level of something that the module system should support. A jlink plugin (or an update to ExcludeVMPlugin) could detect attempts to create a run-time image that contains both the minimal VM and the java.management module but may not be worth it. In any case, a run-time image with the minimal VM will fail with exceptions like this: Exception in thread "main" java.lang.InternalError: Unsupported Management version at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139) at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:259) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:249) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2413) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:849) at java.base/java.lang.System.loadLibrary(System.java:2045) at java.management/java.lang.management.ManagementFactory.lambda$loadNativeLib$8(ManagementFactory.java:1025) at java.base/java.security.AccessController.doPrivileged(AccessController.java:319) at java.management/java.lang.management.ManagementFactory.loadNativeLib(ManagementFactory.java:1024) at java.management/java.lang.management.ManagementFactory.(ManagementFactory.java:1019) ------------- PR: https://git.openjdk.org/jdk/pull/9718 From dholmes at openjdk.org Thu Aug 4 09:06:01 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Aug 2022 09:06:01 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null [v2] In-Reply-To: References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: On Wed, 3 Aug 2022 18:39:19 GMT, Aleksey Shipilev wrote: >> These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL: >> >> >> static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS) >> NOT_MANAGEMENT_RETURN_(NULL); >> ``` >> >> I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0 >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier1` >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier2` >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Cleaner fix I'm okay with this approach. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9718 From eosterlund at openjdk.org Thu Aug 4 09:09:07 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 09:09:07 GMT Subject: RFR: 8290025: Remove the Sweeper Message-ID: When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: 1. Unlink 2. Global sync 3. Throw away 4. Profit! This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. ------------- Commit messages: - 8290025: Remove the Sweeper Changes: https://git.openjdk.org/jdk/pull/9741/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290025 Stats: 3755 lines in 167 files changed: 550 ins; 2736 del; 469 mod Patch: https://git.openjdk.org/jdk/pull/9741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9741/head:pull/9741 PR: https://git.openjdk.org/jdk/pull/9741 From stefank at openjdk.org Thu Aug 4 09:18:11 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 4 Aug 2022 09:18:11 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 09:02:02 GMT, Erik ?sterlund wrote: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Looks good. Reviewed most code, but left JVMCI, JVMTI, and tests, for others to review. ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 4 09:30:06 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 09:30:06 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: <5spIPfilTUt_4eoKTNReCYUFwJOuMJEaG7_s1nQ6eFU=.2023cfdd-9c5d-4d85-8da2-263bfe2b2bcf@github.com> On Thu, 4 Aug 2022 09:15:19 GMT, Stefan Karlsson wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Looks good. Reviewed most code, but left JVMCI, JVMTI, and tests, for others to review. Thanks for the review, @stefank ------------- PR: https://git.openjdk.org/jdk/pull/9741 From aph at openjdk.org Thu Aug 4 10:42:35 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 4 Aug 2022 10:42:35 GMT Subject: RFR: 8291895: Remove PRAGMA_NONNULL_IGNORED from x86 and AArch64 Message-ID: I fixed the underlying bugs, so the warnings are now superfluous. Build on GCC 11.0.3 and GCC head. ------------- Commit messages: - Merge https://github.com/openjdk/jdk into JDK-8291895 - Remove PRAGMA_NONNULL_IGNORED from x86 and AArch64 Changes: https://git.openjdk.org/jdk/pull/9742/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9742&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291895 Stats: 34 lines in 7 files changed: 0 ins; 33 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9742.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9742/head:pull/9742 PR: https://git.openjdk.org/jdk/pull/9742 From shade at openjdk.org Thu Aug 4 10:55:58 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 4 Aug 2022 10:55:58 GMT Subject: RFR: 8291895: Remove PRAGMA_NONNULL_IGNORED from x86 and AArch64 In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 10:34:28 GMT, Andrew Haley wrote: > I fixed the underlying bugs, so the warnings are now superfluous. Build on GCC 11.0.3 and GCC head. Nice. `PRAGMA_DIAG_POP` should be removed along with `PRAGMA_DIAG_PUSH`. See how Windows/MSVC builds complain about it. This probably warrants retesting on GCCs. ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9742 From shade at openjdk.org Thu Aug 4 11:20:59 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 4 Aug 2022 11:20:59 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null [v2] In-Reply-To: References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: On Thu, 4 Aug 2022 09:04:00 GMT, David Holmes wrote: > I'm okay with this approach. Thanks. Thanks! Any other reviews? ------------- PR: https://git.openjdk.org/jdk/pull/9718 From luhenry at openjdk.org Thu Aug 4 12:00:35 2022 From: luhenry at openjdk.org (Ludovic Henry) Date: Thu, 4 Aug 2022 12:00:35 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: <5spIPfilTUt_4eoKTNReCYUFwJOuMJEaG7_s1nQ6eFU=.2023cfdd-9c5d-4d85-8da2-263bfe2b2bcf@github.com> References: <5spIPfilTUt_4eoKTNReCYUFwJOuMJEaG7_s1nQ6eFU=.2023cfdd-9c5d-4d85-8da2-263bfe2b2bcf@github.com> Message-ID: <3tgDyKLzqlYnLTulogeM3emB5jACSvlRe52BzfOKebw=.7cef7288-0bf0-4802-bc20-6358755ff3e3@github.com> On Thu, 4 Aug 2022 09:26:25 GMT, Erik ?sterlund wrote: >> Looks good. Reviewed most code, but left JVMCI, JVMTI, and tests, for others to review. > > Thanks for the review, @stefank Hi @fisk, thanks for the amazing cleanup! We've had a bunch of issues with the code sweeper and AsyncGetCallTrace with trying to unwind from dead code blobs (or what looked like it at least). Have you run some stress tests for AsyncGetCallTrace and this change? It may be something we can look into to make sure it doesn't increase the chances of crashes, or even reduces the chances of crashes. CC @jbachorik @parttimenerd ------------- PR: https://git.openjdk.org/jdk/pull/9741 From bulasevich at openjdk.org Thu Aug 4 12:17:59 2022 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 4 Aug 2022 12:17:59 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 09:02:02 GMT, Erik ?sterlund wrote: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Hi Erik, The change breaks the ARM32 port as the nmethod entry barriers are not implemented there yet. We need a way to work without nmethod entry barriers for the ARM32 platform. # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/barrierSetNMethod_arm.cpp:38 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/boris/jdk-fisk/src/hotspot/cpu/arm/gc/shared/barrierSetNMethod_arm.cpp:38), pid=10206, tid=10207 # Error: ShouldNotReachHere() # # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.boris.jdk-fisk) # Java VM: OpenJDK Server VM (fastdebug 20-internal-adhoc.boris.jdk-fisk, mixed mode, g1 gc, linux-arm) # Problematic frame: # V [libjvm.so+0x2bd610] BarrierSetNMethod::is_armed(nmethod*)+0x2c ------------- PR: https://git.openjdk.org/jdk/pull/9741 From dholmes at openjdk.org Thu Aug 4 12:30:58 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Aug 2022 12:30:58 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v3] In-Reply-To: <1e2Wlr-NZZrEOHOFHhcswO8e2N4OQfcVKUnCD6f7tag=.cf3f451c-6ec7-4164-a3e3-39146a954e75@github.com> References: <1e2Wlr-NZZrEOHOFHhcswO8e2N4OQfcVKUnCD6f7tag=.cf3f451c-6ec7-4164-a3e3-39146a954e75@github.com> Message-ID: On Tue, 2 Aug 2022 12:45:49 GMT, Harold Seigel wrote: >> Seems odd to display as major:minor when it is stored as minor:major > > I think it seems more natural to display the major version first, but I can change it if you prefer. I think it should match the underlying representation else it may cause someone trying to debug a failure to look at the wrong part of the flags value, not realizing the printed value has the opposite format of the actual raw value. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From coleenp at openjdk.org Thu Aug 4 12:38:55 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Aug 2022 12:38:55 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v3] In-Reply-To: References: <1e2Wlr-NZZrEOHOFHhcswO8e2N4OQfcVKUnCD6f7tag=.cf3f451c-6ec7-4164-a3e3-39146a954e75@github.com> Message-ID: On Thu, 4 Aug 2022 12:28:51 GMT, David Holmes wrote: >> I think it seems more natural to display the major version first, but I can change it if you prefer. > > I think it should match the underlying representation else it may cause someone trying to debug a failure to look at the wrong part of the flags value, not realizing the printed value has the opposite format of the actual raw value. Do humans read this or computers? A human would want major:minor because that would make more sense. Isn't this a test? Just a drive by comment. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From eosterlund at openjdk.org Thu Aug 4 12:41:53 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 12:41:53 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: <5spIPfilTUt_4eoKTNReCYUFwJOuMJEaG7_s1nQ6eFU=.2023cfdd-9c5d-4d85-8da2-263bfe2b2bcf@github.com> References: <5spIPfilTUt_4eoKTNReCYUFwJOuMJEaG7_s1nQ6eFU=.2023cfdd-9c5d-4d85-8da2-263bfe2b2bcf@github.com> Message-ID: <0JwV97VNMkk_G_Q3t5_yzIIdOu70eTOO6qszhXFskKc=.632b192a-4f51-4ad6-b82a-c3212750b0b2@github.com> On Thu, 4 Aug 2022 09:26:25 GMT, Erik ?sterlund wrote: >> Looks good. Reviewed most code, but left JVMCI, JVMTI, and tests, for others to review. > > Thanks for the review, @stefank > Hi @fisk, thanks for the amazing cleanup! We've had a bunch of issues with the code sweeper and AsyncGetCallTrace with trying to unwind from dead code blobs (or what looked like it at least). Have you run some stress tests for AsyncGetCallTrace and this change? It may be something we can look into to make sure it doesn't increase the chances of crashes, or even reduces the chances of crashes. CC @jbachorik @parttimenerd I would certainly appreciate your help in stress testing that. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 4 12:41:54 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 12:41:54 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 12:14:40 GMT, Boris Ulasevich wrote: > Hi Erik, > > > > The change breaks the ARM32 port as the nmethod entry barriers are not implemented there yet. We need a way to work without nmethod entry barriers for the ARM32 platform. > > > > ``` > > # To suppress the following error report, specify this argument > > # after -XX: or in .hotspotrc: SuppressErrorAt=/barrierSetNMethod_arm.cpp:38 > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # Internal Error (/home/boris/jdk-fisk/src/hotspot/cpu/arm/gc/shared/barrierSetNMethod_arm.cpp:38), pid=10206, tid=10207 > > # Error: ShouldNotReachHere() > > # > > # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.boris.jdk-fisk) > > # Java VM: OpenJDK Server VM (fastdebug 20-internal-adhoc.boris.jdk-fisk, mixed mode, g1 gc, linux-arm) > > # Problematic frame: > > # V [libjvm.so+0x2bd610] BarrierSetNMethod::is_armed(nmethod*)+0x2c > > ``` Is there a plan for the arm32 port to support nmethod entry barriers? I would really appreciate if the solution to this problem is that arm32 implements nmethod entry barriers. You only need to support the STW data and code patching variation, and it should do pretty much exactly what said AArch64 port does. Arm32 is the only platform I know of that doesn't support nmethod entry barriers, and IMO the JVM should be able to assume this is a feature that we can rely on. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From bulasevich at openjdk.org Thu Aug 4 12:41:56 2022 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 4 Aug 2022 12:41:56 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 09:02:02 GMT, Erik ?sterlund wrote: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Erik, A time ago (not the current code base under review) I noticed that your code sweeper algorithm is more aggressive. Capturing data from output of the -XX:+PrintMethodFlushing option (since the option does not exist in your code, I've added the printout of CodeCache::unallocated_capacity), I build a CodeCache capacity picture while the application run (jmh renaissance benchmark with -f 0 option). Before the changes, free space was steadily declining. With your change, cold methods were quickly cleaned up despite the fact that the cache is less than half full. (I try to insert pictures here: before and after the change) ![before](https://user-images.githubusercontent.com/42576543/182845087-c2631745-6662-46c2-8fd0-578be35b1163.png) ![remove-the-sweeper](https://user-images.githubusercontent.com/42576543/182845246-d3e19628-1a8d-4d8f-8673-c5fd33b5fe4a.png) My concern is that there may be performance degradation in cases where the application periodically changes activity while running. thanks, Boris ------------- PR: https://git.openjdk.org/jdk/pull/9741 From aph at openjdk.org Thu Aug 4 12:50:39 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 4 Aug 2022 12:50:39 GMT Subject: RFR: 8291895: Remove PRAGMA_NONNULL_IGNORED from x86 and AArch64 In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 10:52:27 GMT, Aleksey Shipilev wrote: > Nice. > > `PRAGMA_DIAG_POP` should be removed along with `PRAGMA_DIAG_PUSH`. See how Windows/MSVC builds complain about it. This probably warrants retesting on GCCs. LOL! I never even noticed them. :-) ------------- PR: https://git.openjdk.org/jdk/pull/9742 From hseigel at openjdk.org Thu Aug 4 12:51:33 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Thu, 4 Aug 2022 12:51:33 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v4] In-Reply-To: References: Message-ID: <2B8K53vBTN0cViZGcJzxYRbKGpf90ac9YpMwF_wwWkk=.8119e535-c2d2-4f7f-a0c1-0514c91372ab@github.com> > Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. > > The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: change test to display minor_verion:major_version ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9688/files - new: https://git.openjdk.org/jdk/pull/9688/files/941971dc..b71a79a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9688&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9688&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9688.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9688/head:pull/9688 PR: https://git.openjdk.org/jdk/pull/9688 From hseigel at openjdk.org Thu Aug 4 12:51:33 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Thu, 4 Aug 2022 12:51:33 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v4] In-Reply-To: References: <1e2Wlr-NZZrEOHOFHhcswO8e2N4OQfcVKUnCD6f7tag=.cf3f451c-6ec7-4164-a3e3-39146a954e75@github.com> Message-ID: <043kmQmHRGb3RBQY7PtP5HwXuDnKpOYFRbFJsOM00I8=.8efda682-0197-472e-a071-26207f0a6930@github.com> On Thu, 4 Aug 2022 12:28:51 GMT, David Holmes wrote: >> I think it seems more natural to display the major version first, but I can change it if you prefer. > > I think it should match the underlying representation else it may cause someone trying to debug a failure to look at the wrong part of the flags value, not realizing the printed value has the opposite format of the actual raw value. @dholmes-ora Please see latest commit that changes the test to display minor:major. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From eosterlund at openjdk.org Thu Aug 4 12:54:56 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 12:54:56 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 12:38:50 GMT, Boris Ulasevich wrote: > Erik, > > > > A time ago (not the current code base under review) I noticed that your code sweeper algorithm is more aggressive. > > Capturing data from output of the -XX:+PrintMethodFlushing option (since the option does not exist in your code, > > I've added the printout of CodeCache::unallocated_capacity), I build a CodeCache capacity picture > > while the application run (jmh renaissance benchmark with -f 0 option). Before the changes, free space was steadily declining. > > With your change, cold methods were quickly cleaned up despite the fact that the cache is less than half full. > > > > (I try to insert pictures here: before and after the change) > > ![before](https://user-images.githubusercontent.com/42576543/182845087-c2631745-6662-46c2-8fd0-578be35b1163.png) > > ![remove-the-sweeper](https://user-images.githubusercontent.com/42576543/182845246-d3e19628-1a8d-4d8f-8673-c5fd33b5fe4a.png) > > > > My concern is that there may be performance degradation in cases where the application periodically changes activity while running. > > > > thanks, > > Boris I would be interested in seeing what the graph looks like with my current proposed change. I don't know what state my prototype was in when you performed measurements, and the heuristics have been tweaked. Having said that, if half the code cache was filled up, it sounds like it's getting to a point where you do want to flush things that haven't been used in a long while, to avoid getting into the "red zone" of aggressive sweeping at 90%, in order to free up space for currently hot code. To me it looks like it is working kind of as expected. Was there a regression due to unloading perceivably cold code? You can get more information about the heuristic decisions with -Xlog:codecache with my change. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From aph at openjdk.org Thu Aug 4 13:01:18 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 4 Aug 2022 13:01:18 GMT Subject: RFR: 8291895: Remove PRAGMA_NONNULL_IGNORED from x86 and AArch64 [v2] In-Reply-To: References: Message-ID: > I fixed the underlying bugs, so the warnings are now superfluous. Build on GCC 11.0.3 and GCC head. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: 8291895: Remove PRAGMA_NONNULL_IGNORED from x86 and AArch64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9742/files - new: https://git.openjdk.org/jdk/pull/9742/files/5c19e516..504badba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9742&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9742&range=00-01 Stats: 7 lines in 6 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9742.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9742/head:pull/9742 PR: https://git.openjdk.org/jdk/pull/9742 From dholmes at openjdk.org Thu Aug 4 13:09:17 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Aug 2022 13:09:17 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v4] In-Reply-To: <2B8K53vBTN0cViZGcJzxYRbKGpf90ac9YpMwF_wwWkk=.8119e535-c2d2-4f7f-a0c1-0514c91372ab@github.com> References: <2B8K53vBTN0cViZGcJzxYRbKGpf90ac9YpMwF_wwWkk=.8119e535-c2d2-4f7f-a0c1-0514c91372ab@github.com> Message-ID: On Thu, 4 Aug 2022 12:51:33 GMT, Harold Seigel wrote: >> Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. >> >> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > change test to display minor_verion:major_version Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9688 From dholmes at openjdk.org Thu Aug 4 13:09:18 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Aug 2022 13:09:18 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v4] In-Reply-To: <043kmQmHRGb3RBQY7PtP5HwXuDnKpOYFRbFJsOM00I8=.8efda682-0197-472e-a071-26207f0a6930@github.com> References: <1e2Wlr-NZZrEOHOFHhcswO8e2N4OQfcVKUnCD6f7tag=.cf3f451c-6ec7-4164-a3e3-39146a954e75@github.com> <043kmQmHRGb3RBQY7PtP5HwXuDnKpOYFRbFJsOM00I8=.8efda682-0197-472e-a071-26207f0a6930@github.com> Message-ID: On Thu, 4 Aug 2022 12:47:13 GMT, Harold Seigel wrote: >> I think it should match the underlying representation else it may cause someone trying to debug a failure to look at the wrong part of the flags value, not realizing the printed value has the opposite format of the actual raw value. > > @dholmes-ora Please see latest commit that changes the test to display minor:major. Latest change is good. @coleenp this is for humans reading failed test output. If it reports "expected 0:1 but got 1:1" then the natural tendency would be to look for an issue in the upper word, when in fact the problem is in the lower word. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From hseigel at openjdk.org Thu Aug 4 13:14:32 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Thu, 4 Aug 2022 13:14:32 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information [v4] In-Reply-To: <2B8K53vBTN0cViZGcJzxYRbKGpf90ac9YpMwF_wwWkk=.8119e535-c2d2-4f7f-a0c1-0514c91372ab@github.com> References: <2B8K53vBTN0cViZGcJzxYRbKGpf90ac9YpMwF_wwWkk=.8119e535-c2d2-4f7f-a0c1-0514c91372ab@github.com> Message-ID: On Thu, 4 Aug 2022 12:51:33 GMT, Harold Seigel wrote: >> Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. >> >> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > change test to display minor_verion:major_version Thanks Roger, David, Joe, and Coleen for your comments and reviews! ------------- PR: https://git.openjdk.org/jdk/pull/9688 From hseigel at openjdk.org Thu Aug 4 13:15:57 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Thu, 4 Aug 2022 13:15:57 GMT Subject: Integrated: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 18:02:46 GMT, Harold Seigel wrote: > Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. > > The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: a3040fcc Author: Harold Seigel URL: https://git.openjdk.org/jdk/commit/a3040fcc2baa48c19d9525b3539863a71fa5781d Stats: 812 lines in 9 files changed: 811 ins; 0 del; 1 mod 8291360: Create entry points to expose low-level class file information Reviewed-by: dholmes, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/9688 From duke at openjdk.org Thu Aug 4 13:33:18 2022 From: duke at openjdk.org (Johannes Bechberger) Date: Thu, 4 Aug 2022 13:33:18 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: <3tgDyKLzqlYnLTulogeM3emB5jACSvlRe52BzfOKebw=.7cef7288-0bf0-4802-bc20-6358755ff3e3@github.com> References: <5spIPfilTUt_4eoKTNReCYUFwJOuMJEaG7_s1nQ6eFU=.2023cfdd-9c5d-4d85-8da2-263bfe2b2bcf@github.com> <3tgDyKLzqlYnLTulogeM3emB5jACSvlRe52BzfOKebw=.7cef7288-0bf0-4802-bc20-6358755ff3e3@github.com> Message-ID: On Thu, 4 Aug 2022 11:57:39 GMT, Ludovic Henry wrote: >> Thanks for the review, @stefank > > Hi @fisk, thanks for the amazing cleanup! We've had a bunch of issues with the code sweeper and AsyncGetCallTrace with trying to unwind from dead code blobs (or what looked like it at least). Have you run some stress tests for AsyncGetCallTrace and this change? It may be something we can look into to make sure it doesn't increase the chances of crashes, or even reduces the chances of crashes. CC @jbachorik @parttimenerd @luhenry @fisk I'm going to stress test it with my [jdk-profiling-tester](https://github.com/parttimenerd/jdk-profiling-tester) on M1 and x86 over night (comparing it with the current master). ------------- PR: https://git.openjdk.org/jdk/pull/9741 From duke at openjdk.org Thu Aug 4 13:36:51 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Thu, 4 Aug 2022 13:36:51 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v5] In-Reply-To: References: Message-ID: > @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) > > Description from the original issue: >> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >> >> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >> >> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. > > Testing: Tier 1-3, 4-7 non-windows > Windows tier 4-7 still queued Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Remove double counting _perf_total_buckets_deallocated_count ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9713/files - new: https://git.openjdk.org/jdk/pull/9713/files/048f2f71..f8eaa683 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=03-04 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9713.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9713/head:pull/9713 PR: https://git.openjdk.org/jdk/pull/9713 From eosterlund at openjdk.org Thu Aug 4 14:05:54 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 14:05:54 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: <3tgDyKLzqlYnLTulogeM3emB5jACSvlRe52BzfOKebw=.7cef7288-0bf0-4802-bc20-6358755ff3e3@github.com> References: <5spIPfilTUt_4eoKTNReCYUFwJOuMJEaG7_s1nQ6eFU=.2023cfdd-9c5d-4d85-8da2-263bfe2b2bcf@github.com> <3tgDyKLzqlYnLTulogeM3emB5jACSvlRe52BzfOKebw=.7cef7288-0bf0-4802-bc20-6358755ff3e3@github.com> Message-ID: On Thu, 4 Aug 2022 11:57:39 GMT, Ludovic Henry wrote: >> Thanks for the review, @stefank > > Hi @fisk, thanks for the amazing cleanup! We've had a bunch of issues with the code sweeper and AsyncGetCallTrace with trying to unwind from dead code blobs (or what looked like it at least). Have you run some stress tests for AsyncGetCallTrace and this change? It may be something we can look into to make sure it doesn't increase the chances of crashes, or even reduces the chances of crashes. CC @jbachorik @parttimenerd > @luhenry @fisk I'm going to stress test it with my [jdk-profiling-tester](https://github.com/parttimenerd/jdk-profiling-tester) on M1 and x86 over night (comparing it with the current master). Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/9741 From duke at openjdk.org Thu Aug 4 14:34:59 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Thu, 4 Aug 2022 14:34:59 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 09:02:02 GMT, Erik ?sterlund wrote: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. There are still 15 comments that refer to `zombie` in the `hotspot/share/**` codebase. Would be nice to nuke them all to avoid stale, confusing and misleading information. There is also some printing and non product flags which needs an overhaul in what terminology to use, and with what meaning, in the world where the sweeper and zombie nmethods are gone. The second part is just an observation of future work, but it would be nice to have this patch at least deliver with no stale zombie comments.
Details * **Comments** * `src/hotspot/share/code/codeCache.cpp:1290` * Remove? Or just call when unloaded/unloading. * `src/hotspot/share/code/compiledIC.cpp:370` * Rephrase, confusing. * `src/hotspot/share/code/compiledMethod.cpp:313` * Rephrase, confusing. * `src/hotspot/share/code/compiledMethod.cpp:511` * Remove? * `src/hotspot/share/code/compiledMethod.cpp:515` * Remove? Confusing. * `src/hotspot/share/code/compiledMethod.cpp:596` * Remove zombie? Also what is unloaded nmethod in this context. * `src/hotspot/share/code/dependencyContext.cpp:71` * Rephrase, confusing. * `src/hotspot/share/code/nmethod.cpp:1166` * Remove? * `src/hotspot/share/code/nmethod.cpp:1171` * Remove? Confusing. * `src/hotspot/share/code/nmethod.cpp:1184` * Remove? Confusing. * `src/hotspot/share/code/nmethod.cpp:1422` * Rephrase, confusing. Many zombie interactions/assumptions in one comment. * `src/hotspot/share/code/nmethod.hpp:268` * Remove. `zombie`, `unloaded` enums no longer exist * `src/hotspot/share/compiler/compileTask.cpp:243` * Rephrase or remove, confusing. * `src/hotspot/share/oops/method.cpp:1168` * Rephrase, confusing. * `src/hotspot/share/prims/jvmtiImpl.cpp:1079` * Rephrase, confusing. Also meaning of unloaded. * **Not product flag** * `ZombieALot` and `ZombieALotInterval` * Needs an overhaul with respects to what terminology to use and what it is suppose to represent * **Printing** * `src/hotspot/share/code/codeCache.cpp:1643` * `src/hotspot/share/code/codeHeapState.cpp` * Needs an overhaul with respects to what terminology to use and what it is suppose to represent
------------- PR: https://git.openjdk.org/jdk/pull/9741 From shade at openjdk.org Thu Aug 4 14:37:10 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 4 Aug 2022 14:37:10 GMT Subject: RFR: 8291895: Remove PRAGMA_NONNULL_IGNORED from x86 and AArch64 [v2] In-Reply-To: References: Message-ID: <4aw_py0ajDnAL1Q2LBi3i3bl7vTcLzV9B-1H-aiUyoc=.0f6e545b-3a94-4b44-ae59-07aaf2418a55@github.com> On Thu, 4 Aug 2022 13:01:18 GMT, Andrew Haley wrote: >> I fixed the underlying bugs, so the warnings are now superfluous. Build on GCC 11.0.3 and GCC head. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > 8291895: Remove PRAGMA_NONNULL_IGNORED from x86 and AArch64 GCC 11 x86_64 and x86_32 builds completed fine. GCC 12 x86_64 build completed fine. Looks good, as long as GHA is happy. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9742 From hseigel at openjdk.org Thu Aug 4 14:43:34 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Thu, 4 Aug 2022 14:43:34 GMT Subject: RFR: 8291459: JVM crash with GenerateOopMap::error_work(char const*, __va_list_tag*) Message-ID: The JVM fails when generating oop maps for method getAlphanumericCode(int) in bug_file/com/google/zxing/qrcode/encoder/Encoder.javap because the last bytecode in the method is an unreachable conditional branch at byecode index 11131: 11124: ireturn 11125: iinc 41, 1 11128: iload 41 11130: iconst_2 11131: if_icmple 291 The class file (Encoder.class) containing getAlphanumericCode(int) has a class file version of 49. So it is verified by the old verifier, which allows methods to end in a conditional branch provided that the conditional branch is unreachable during method execution. This fix changes GenerateOopMap::jump_targets_do() to handle such methods. The fix was tested by running the user's failing program, the new regression test, Mach5 tiers 1-2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linu x64, and the JC Lang,VM, and API tests locally on Linux x64. Please review. Thanks, Harold ------------- Commit messages: - 8291459: JVM crash with GenerateOopMap::error_work(char const*, __va_list_tag*) Changes: https://git.openjdk.org/jdk/pull/9745/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9745&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291459 Stats: 118 lines in 3 files changed: 117 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9745.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9745/head:pull/9745 PR: https://git.openjdk.org/jdk/pull/9745 From duke at openjdk.org Thu Aug 4 15:11:30 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Thu, 4 Aug 2022 15:11:30 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v5] In-Reply-To: References: Message-ID: <4thNAU1KsYJJNHFaWLsYiD9bg2iEPfoHRjFjtxYsUdQ=.c6141054-ec9d-4121-b496-4ef8c6b417e2@github.com> On Thu, 4 Aug 2022 13:36:51 GMT, Axel Boldt-Christmas wrote: >> @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) >> >> Description from the original issue: >>> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >>> >>> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >>> >>> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. >> >> Testing: Tier 1-7 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Remove double counting _perf_total_buckets_deallocated_count The perf counters were double counting some deallocations. The release and purge code was already handling it. This code would just double count any `not_unloading` dependencies. ------------- PR: https://git.openjdk.org/jdk/pull/9713 From duke at openjdk.org Thu Aug 4 15:11:30 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Thu, 4 Aug 2022 15:11:30 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v5] In-Reply-To: References: <5JfLyDDTi0H7WRva8W0WV7hI3xKvxVo7mPyaWzpx1pw=.a682010e-356f-4972-a343-a2058fa2b2ef@github.com> Message-ID: On Wed, 3 Aug 2022 13:41:41 GMT, Axel Boldt-Christmas wrote: >> You are correct that nm should all be at least `unloading`, as if a klass is unloading all dependent `nmethods` should be unloading. So this code should boil down to: >> ```C++ >> void DependencyContext::remove_all_dependents() { >> nmethodBucket* b = dependencies_not_unloading(); >> set_dependencies(NULL); >> assert(b == nullptr, "All dependents should be unloading"); >> } >> >> As `dependencies_not_unloading()` will unlink and release every dependent that is `unloading`. >> Have run stress tests on that change and no violations were found. >> Will push and test this change. > >> You are correct that nm should all be at least `unloading`, as if a klass is unloading all dependent `nmethods` should be unloading. So this code should boil down to: >> >> ```c++ >> void DependencyContext::remove_all_dependents() { >> nmethodBucket* b = dependencies_not_unloading(); >> set_dependencies(NULL); >> assert(b == nullptr, "All dependents should be unloading"); >> } >> ``` >> >> As `dependencies_not_unloading()` will unlink and release every dependent that is `unloading`. Have run stress tests on that change and no violations were found. Will push and test this change. > > From testing this seems not to be the case. Will investigate some more. So there are dependents that do no become `unloading` when the klass unloads. I would like to find out more in detail what you want to ensure, or situation you are afraid that might occur. I've tried to investigate what types of dependent nmethods are not `unloading` when the the klass with a dependency is unloaded. I suspect it has to do with class loading and compilation order. From what I understand the nmethod will only be unloading if it has a reference to a dead oop inside it. So the compiler must generate code which is dependent without having an oop baked in. I do find it difficult to reason about the lifetime of these dependencies (at least the logical part, the release, purge cycle of the memory seems pretty straight forward) and nmethods (the sweeper removal does make the nmethod lifecycle a lot easier to reason about tough). I am really interested in what you think. As this change is just always running an edge case which can happen in mainline. This just makes it default. Hotspot seems to have relied on this interaction being this way for some time. The windows machines finally woke up and the patch passed tier 1-7 ------------- PR: https://git.openjdk.org/jdk/pull/9713 From bulasevich at openjdk.org Thu Aug 4 15:39:03 2022 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 4 Aug 2022 15:39:03 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 12:51:38 GMT, Erik ?sterlund wrote: > I would be interested in seeing what the graph looks like with my current proposed change. I don't know what state my prototype was in when you performed measurements, and the heuristics have been tweaked. Below is a CodeCache chart (numbers from -Xlog:codecache this time) on the current proposed change. App gets 250MB of CodeCache, and executes 23 independent benchmarks. ![???????????](https://user-images.githubusercontent.com/42576543/182878624-c2092502-5033-42cc-805a-8a16ef86fb40.png) > Was there a regression due to unloading perceivably cold code? No, specific of my run is a set of independent benchmarks: warmup, iteration, warmup, iteration - it does not get regression unless the CodeHeap is completely over. Sweeper itself does not affect performance, I checked it. My concern is about user applications. > Having said that, if half the code cache was filled up, it sounds like it's getting to a point where you do want to flush things that haven't been used in a long while, to avoid getting into the "red zone" of aggressive sweeping at 90%, in order to free up space for currently hot code. To me it looks like it is working kind of as expected. In my picture, we can see that the methods are swept out when the CodeCache is 70% free. For me it is not expected. Even a super-cold method can come back. We should not flush it when we are far from memory starvation. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From bulasevich at openjdk.org Thu Aug 4 15:48:12 2022 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 4 Aug 2022 15:48:12 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 12:37:43 GMT, Erik ?sterlund wrote: > Is there a plan for the arm32 port to support nmethod entry barriers? I created a JBS record for this task: [JDK-8291302](https://bugs.openjdk.org/browse/JDK-8291302) I do not have time for this task now. If no one takes it, I hope to find time for this in the late autumn. For now, please, make a "short term solution where if nmethod aging is turned off, you can run without nmethod entry barriers". thank you! ------------- PR: https://git.openjdk.org/jdk/pull/9741 From duke at openjdk.org Thu Aug 4 15:58:56 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Thu, 4 Aug 2022 15:58:56 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 09:02:02 GMT, Erik ?sterlund wrote: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. src/hotspot/share/code/nmethod.cpp line 1541: > 1539: Universe::heap()->unregister_nmethod(this); > 1540: } > 1541: flush_dependencies(/*delete_immediately*/true); `flush_dependencies` is now only ever called with `false` ------------- PR: https://git.openjdk.org/jdk/pull/9741 From aph at openjdk.org Thu Aug 4 16:15:03 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 4 Aug 2022 16:15:03 GMT Subject: Integrated: 8291895: Remove PRAGMA_NONNULL_IGNORED from x86 and AArch64 In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 10:34:28 GMT, Andrew Haley wrote: > I fixed the underlying bugs, so the warnings are now superfluous. Build on GCC 11.0.3 and GCC head. This pull request has now been integrated. Changeset: 966ab219 Author: Andrew Haley URL: https://git.openjdk.org/jdk/commit/966ab219b4584bcd561112838c2bde6591ecb064 Stats: 41 lines in 7 files changed: 0 ins; 40 del; 1 mod 8291895: Remove PRAGMA_NONNULL_IGNORED from x86 and AArch64 Reviewed-by: shade ------------- PR: https://git.openjdk.org/jdk/pull/9742 From duke at openjdk.org Thu Aug 4 16:31:27 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Thu, 4 Aug 2022 16:31:27 GMT Subject: Integrated: 8283232: x86: Improve vector broadcast operations In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 01:19:24 GMT, Quan Anh Mai wrote: > Hi, > > This patch improves the generation of broadcasting a scalar in several ways: > > - As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines. > - Vector broadcasting should prefer rematerialising to spilling when register pressure is high. > - Load vectors using the same kind (integral vs floating point) of instructions as that of the results to avoid potential data bypass delay > > With this patch, the result of the added benchmark, which performs some operations with a really high register pressure, on my machine with Intel i7-7700HQ (avx2) is as follow: > > Before After > Benchmark Mode Cnt Score Error Score Error Units Gain > SpiltReplicate.testDouble avgt 5 42.621 ? 0.598 38.771 ? 0.797 ns/op +9.03% > SpiltReplicate.testFloat avgt 5 42.245 ? 1.464 38.603 ? 0.367 ns/op +8.62% > SpiltReplicate.testInt avgt 5 20.581 ? 5.791 13.755 ? 0.375 ns/op +33.17% > SpiltReplicate.testLong avgt 5 17.794 ? 4.781 13.663 ? 0.387 ns/op +23.22% > > As expected, the constant table sizes shrink significantly from 1024 bytes to 256 bytes for `long`/`double` and 128 bytes for `int`/`float` cases. > > This patch also removes some redundant code paths and renames some incorrectly named instructions. > > Thank you very much. This pull request has now been integrated. Changeset: 92d2982f Author: Quan Anh Mai Committer: Jatin Bhateja URL: https://git.openjdk.org/jdk/commit/92d2982f3f4ecf7d17df4267bd67af2490badd1e Stats: 551 lines in 14 files changed: 357 ins; 85 del; 109 mod 8283232: x86: Improve vector broadcast operations Reviewed-by: kvn, jbhateja ------------- PR: https://git.openjdk.org/jdk/pull/7832 From hseigel at openjdk.org Thu Aug 4 17:18:16 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Thu, 4 Aug 2022 17:18:16 GMT Subject: RFR: 8291459: JVM crash with GenerateOopMap::error_work(char const*, __va_list_tag*) [v2] In-Reply-To: References: Message-ID: > The JVM fails when generating oop maps for method getAlphanumericCode(int) in bug_file/com/google/zxing/qrcode/encoder/Encoder.javap because the last bytecode in the method is an unreachable conditional branch at byecode index 11131: > > 11124: ireturn > 11125: iinc 41, 1 > 11128: iload 41 > 11130: iconst_2 > 11131: if_icmple 291 > > The class file (Encoder.class) containing getAlphanumericCode(int) has a class file version of 49. So it is verified by the old verifier, which allows methods to end in a conditional branch provided that the conditional branch is unreachable during method execution. > > This fix changes GenerateOopMap::jump_targets_do() to handle such methods. > > The fix was tested by running the user's failing program, the new regression test, Mach5 tiers 1-2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linu x64, and the JC Lang,VM, and API tests locally on Linux x64. > > Please review. > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: remove CreateCodedumpOnCrash option ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9745/files - new: https://git.openjdk.org/jdk/pull/9745/files/bdce5b04..4c72e190 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9745&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9745&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9745.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9745/head:pull/9745 PR: https://git.openjdk.org/jdk/pull/9745 From eosterlund at openjdk.org Thu Aug 4 19:25:29 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 19:25:29 GMT Subject: RFR: 8290025: Remove the Sweeper [v2] In-Reply-To: References: Message-ID: <82sPWKCNk4Jv-AkG0DeM2_tklUOqnFoa0sQ-HT_-gAs=.64921f41-6858-4c9d-b430-e648f39c56ae@github.com> > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Feedback v1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9741/files - new: https://git.openjdk.org/jdk/pull/9741/files/5ca520f7..4d11d460 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=00-01 Stats: 355 lines in 42 files changed: 18 ins; 243 del; 94 mod Patch: https://git.openjdk.org/jdk/pull/9741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9741/head:pull/9741 PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 4 19:25:33 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 19:25:33 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 09:02:02 GMT, Erik ?sterlund wrote: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > There are still 15 comments that refer to `zombie` in the `hotspot/share/**` codebase. Would be nice to nuke them all to avoid stale, confusing and misleading information. > > There is also some printing and non product flags which needs an overhaul in what terminology to use, and with what meaning, in the world where the sweeper and zombie nmethods are gone. > > The second part is just an observation of future work, but it would be nice to have this patch at least deliver with no stale zombie comments. > > Details I found all mentions of zombie I could find. Notably left ZombieALot as it has never created zombies, so the name was already wrong and misleading. It should arguably be called DeoptimizeALot or something... but that's obviously already taken. I'd prefer not to not discuss its naming in this PR as it was already wrong and there are enough things to consider as it is in here. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 4 19:25:38 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 19:25:38 GMT Subject: RFR: 8290025: Remove the Sweeper [v2] In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 15:55:20 GMT, Axel Boldt-Christmas wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback v1 > > src/hotspot/share/code/nmethod.cpp line 1541: > >> 1539: Universe::heap()->unregister_nmethod(this); >> 1540: } >> 1541: flush_dependencies(/*delete_immediately*/true); > > `flush_dependencies` is now only ever called with `false` Good catch. I removed it, and some remove_dependent methods that were only used in the true version that is no longer called. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 4 19:34:18 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 19:34:18 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 15:46:12 GMT, Boris Ulasevich wrote: > > Is there a plan for the arm32 port to support nmethod entry barriers? > > I created a JBS record for this task: [JDK-8291302](https://bugs.openjdk.org/browse/JDK-8291302) I do not have time for this task now. If no one takes it, I hope to find time for this in the late autumn. For now, please, make a "short term solution where if nmethod aging is turned off, you can run without nmethod entry barriers". > > thank you! Okay. I put in a special ARM32 mode for you for now. It will work but it won't remove cold nmethods. I really hope we can remove the special mode soon and assume all platforms have nmethod entry barriers. I don't like having special modes. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From kvn at openjdk.org Thu Aug 4 20:14:17 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 4 Aug 2022 20:14:17 GMT Subject: RFR: 8290025: Remove the Sweeper [v2] In-Reply-To: <82sPWKCNk4Jv-AkG0DeM2_tklUOqnFoa0sQ-HT_-gAs=.64921f41-6858-4c9d-b430-e648f39c56ae@github.com> References: <82sPWKCNk4Jv-AkG0DeM2_tklUOqnFoa0sQ-HT_-gAs=.64921f41-6858-4c9d-b430-e648f39c56ae@github.com> Message-ID: On Thu, 4 Aug 2022 19:25:29 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Feedback v1 Initial review of few `code/` files. Will do more later. I am not comfortable with name `unloading` for this process because historically, for me, it is associated with class unloading and "unloading" corresponding nmethods. `cleaning` is more similar with `sweeping`. But it could be only me. src/hotspot/share/ci/ciEnv.cpp line 1076: > 1074: > 1075: // Notify code cache unloading that we are about to allocate, which may > 1076: // or may not require freeing up memory first. Confusing comment. As I understand it could be: `Check if memory should be freed before allocation`. src/hotspot/share/ci/ciEnv.cpp line 1212: > 1210: } > 1211: > 1212: NoSafepointVerifier nsv; There is window after releasing all previous locks and here when nmethod could become dead. I don't see `post_compiled_method()` checking for that. Also I don't see such `NoSafepointVerifier` in `JVMCIRuntime::register_method()`. src/hotspot/share/code/codeCache.cpp line 700: > 698: // used in order to not be classed as cold. > 699: void CodeCache::update_cold_gc_count() { > 700: if (!MethodFlushing || !UseCodeCacheFlushing || NmethodSweepActivity == 0) { Did you test these cases? src/hotspot/share/code/codeCache.cpp line 779: > 777: } > 778: > 779: void CodeCache::on_allocation() { How about `CodeCache::gc_on_allocation()`? Otherwise it is not clear what it does in places where it is called. src/hotspot/share/compiler/compilationLog.hpp line 1: > 1: /* Is it Git hiccup with the file renaming? ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 4 20:24:39 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 20:24:39 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 15:35:29 GMT, Boris Ulasevich wrote: > > I would be interested in seeing what the graph looks like with my current proposed change. I don't know what state my prototype was in when you performed measurements, and the heuristics have been tweaked. > > Below is a CodeCache chart (numbers from -Xlog:codecache this time) on the current proposed change. App gets 250MB of CodeCache, and executes 23 independent benchmarks. > > ![???????????](https://user-images.githubusercontent.com/42576543/182878624-c2092502-5033-42cc-805a-8a16ef86fb40.png) > > > Was there a regression due to unloading perceivably cold code? > > No, specific of my run is a set of independent benchmarks: warmup, iteration, warmup, iteration - it does not get regression unless the CodeHeap is completely over. Sweeper itself does not affect performance, I checked it. My concern is about user applications. > > > Having said that, if half the code cache was filled up, it sounds like it's getting to a point where you do want to flush things that haven't been used in a long while, to avoid getting into the "red zone" of aggressive sweeping at 90%, in order to free up space for currently hot code. To me it looks like it is working kind of as expected. > > In my picture, we can see that the methods are swept out when the CodeCache is 70% free. For me it is not expected. Even a super-cold method can come back. We should not flush it when we are far from memory starvation. 1) It isn't obvious based on the chart that my new strategy unloads more nmethods due to being cold, than we did before. The sweeper before would make nmethods not_entrant in one cycle, but might need 4 cycles to actually be able to delete them. That means that the previous approach had much more floating garbage in the code cache, but that doesn't necessarily imply that the number of nuked nmethods were smaller. The new approach is much more effective and can do all the things necessary to detect cold nmethods and unload them from the code cache, in a single cycle, which immediately brings down the code cache size. It still might be that my new algorithm is more aggressive, but the data does not conclude that. 2) The UseCodeCacheFlushing flag is on by default. Its assumption is that you want to "Remove cold/old nmethods from the code cache". Based on what you are saying, it sounds more like we shouldn't do that at all for some applications where you want super cold nmethods to still be around. I guess this flag can be turned off then, if you have such an application. Note though that if the application for example idles, then there is no allocation rate in the code cache, and my new heuristics won't remove anything, because it is based on how long until the code cache becomes "too full", given the current allocation rate (which is likely 0 when idling), while the old heuristics have been reported to reap the entire code cache in such situations. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 4 20:57:06 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 20:57:06 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: References: Message-ID: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Feedback v2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9741/files - new: https://git.openjdk.org/jdk/pull/9741/files/4d11d460..331ad2f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=01-02 Stats: 10 lines in 5 files changed: 0 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9741/head:pull/9741 PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 4 20:57:10 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 20:57:10 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: References: <82sPWKCNk4Jv-AkG0DeM2_tklUOqnFoa0sQ-HT_-gAs=.64921f41-6858-4c9d-b430-e648f39c56ae@github.com> Message-ID: <4EL9HeQWuevMHWXimhtoYzsbnaKlBMYXk5pAxwZzhr0=.1780faec-2785-40e8-abf6-cfccf7715323@github.com> On Thu, 4 Aug 2022 20:10:16 GMT, Vladimir Kozlov wrote: > Initial review of few `code/` files. Will do more later. > > I am not comfortable with name `unloading` for this process because historically, for me, it is associated with class unloading and "unloading" corresponding nmethods. `cleaning` is more similar with `sweeping`. But it could be only me. Thanks for reviewing this change! I'm using the term "code cache unloading", because that is what we have always called unloading of nmethods triggered by the GC. And now it is the GC that owns this completely, so code cache unloading is the way in which nmethods are freed. At least that was my reasoning. I'd like to split the "unloading" parts of the CodeCache to a separate file, but I decided it's better to do that in a separate patch, as this patch is large enough and I don't want to move around code as well in it. Hope this makes sense. > src/hotspot/share/ci/ciEnv.cpp line 1076: > >> 1074: >> 1075: // Notify code cache unloading that we are about to allocate, which may >> 1076: // or may not require freeing up memory first. > > Confusing comment. As I understand it could be: `Check if memory should be freed before allocation`. Fixed. > src/hotspot/share/code/codeCache.cpp line 700: > >> 698: // used in order to not be classed as cold. >> 699: void CodeCache::update_cold_gc_count() { >> 700: if (!MethodFlushing || !UseCodeCacheFlushing || NmethodSweepActivity == 0) { > > Did you test these cases? Yes. > src/hotspot/share/code/codeCache.cpp line 779: > >> 777: } >> 778: >> 779: void CodeCache::on_allocation() { > > How about `CodeCache::gc_on_allocation()`? Otherwise it is not clear what it does in places where it is called. Fixed. > src/hotspot/share/compiler/compilationLog.hpp line 1: > >> 1: /* > > Is it Git hiccup with the file renaming? Yes, haha. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 4 20:57:12 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 20:57:12 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: <4EL9HeQWuevMHWXimhtoYzsbnaKlBMYXk5pAxwZzhr0=.1780faec-2785-40e8-abf6-cfccf7715323@github.com> References: <82sPWKCNk4Jv-AkG0DeM2_tklUOqnFoa0sQ-HT_-gAs=.64921f41-6858-4c9d-b430-e648f39c56ae@github.com> <4EL9HeQWuevMHWXimhtoYzsbnaKlBMYXk5pAxwZzhr0=.1780faec-2785-40e8-abf6-cfccf7715323@github.com> Message-ID: On Thu, 4 Aug 2022 20:51:03 GMT, Erik ?sterlund wrote: >> src/hotspot/share/compiler/compilationLog.hpp line 1: >> >>> 1: /* >> >> Is it Git hiccup with the file renaming? > > Yes, haha. Git automagically computes renaming based on how similar the files are. I just moved the CompilationLog class, and removed the file it came from, so it thinks it's a "rename". One of the pitfalls of git. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 4 20:58:46 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 4 Aug 2022 20:58:46 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: References: <82sPWKCNk4Jv-AkG0DeM2_tklUOqnFoa0sQ-HT_-gAs=.64921f41-6858-4c9d-b430-e648f39c56ae@github.com> Message-ID: On Thu, 4 Aug 2022 20:01:22 GMT, Vladimir Kozlov wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback v2 > > src/hotspot/share/ci/ciEnv.cpp line 1212: > >> 1210: } >> 1211: >> 1212: NoSafepointVerifier nsv; > > There is window after releasing all previous locks and here when nmethod could become dead. I don't see `post_compiled_method()` checking for that. > Also I don't see such `NoSafepointVerifier` in `JVMCIRuntime::register_method()`. The nmethod can only get unloaded at safepoint polls. There aren't any when unlocking. The reason the NSV isn't just crossing the entire scope, is because some locks like Compile_lock will block when we take the lock, just not when we unlock it. Unfortunately I can't put a similar NSV in the JVMCI installer, because when you run JVMCI with native image, there is a setter that uses JNI, which will check for safepoints. However, that only happens if the nmethod failed to install, which doesn't really matter, but it does prevent the NSV from being in the same corresponding location there. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From kvn at openjdk.org Thu Aug 4 22:16:56 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 4 Aug 2022 22:16:56 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: <4EL9HeQWuevMHWXimhtoYzsbnaKlBMYXk5pAxwZzhr0=.1780faec-2785-40e8-abf6-cfccf7715323@github.com> References: <82sPWKCNk4Jv-AkG0DeM2_tklUOqnFoa0sQ-HT_-gAs=.64921f41-6858-4c9d-b430-e648f39c56ae@github.com> <4EL9HeQWuevMHWXimhtoYzsbnaKlBMYXk5pAxwZzhr0=.1780faec-2785-40e8-abf6-cfccf7715323@github.com> Message-ID: On Thu, 4 Aug 2022 20:50:14 GMT, Erik ?sterlund wrote: > > Initial review of few `code/` files. Will do more later. > > I am not comfortable with name `unloading` for this process because historically, for me, it is associated with class unloading and "unloading" corresponding nmethods. `cleaning` is more similar with `sweeping`. But it could be only me. > > Thanks for reviewing this change! I'm using the term "code cache unloading", because that is what we have always called unloading of nmethods triggered by the GC. And now it is the GC that owns this completely, so code cache unloading is the way in which nmethods are freed. At least that was my reasoning. I'd like to split the "unloading" parts of the CodeCache to a separate file, but I decided it's better to do that in a separate patch, as this patch is large enough and I don't want to move around code as well in it. Hope this makes sense. Okay, I agree since it is GC operation now. >> src/hotspot/share/ci/ciEnv.cpp line 1212: >> >>> 1210: } >>> 1211: >>> 1212: NoSafepointVerifier nsv; >> >> There is window after releasing all previous locks and here when nmethod could become dead. I don't see `post_compiled_method()` checking for that. >> Also I don't see such `NoSafepointVerifier` in `JVMCIRuntime::register_method()`. > > The nmethod can only get unloaded at safepoint polls. There aren't any when unlocking. The reason the NSV isn't just crossing the entire scope, is because some locks like Compile_lock will block when we take the lock, just not when we unlock it. > Unfortunately I can't put a similar NSV in the JVMCI installer, because when you run JVMCI with native image, there is a setter that uses JNI, which will check for safepoints. However, that only happens if the nmethod failed to install, which doesn't really matter, but it does prevent the NSV from being in the same corresponding location there. I am talking about concurrent change of nmethod's state. When you **publish** nmethod (set Method::_code) and it is not locked it could be marked non-entrant. It depends on how OS's scheduler run/suspend this compiler's thread. But you are right, unloading only happens in SFP. So the code should be still there and it is still alright to initialize tasks' fields. `nmethod::post_compiled_method_load_event()` has `NoSafepointVerifier` already. Only task's fields settings is not covered. Do you think we still need it here? ------------- PR: https://git.openjdk.org/jdk/pull/9741 From kvn at openjdk.org Thu Aug 4 22:22:35 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 4 Aug 2022 22:22:35 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 20:57:06 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Feedback v2 I looked on other compiler's related code. It is mostly removal of sweeper and CodeAging code. I did not reviewed in detail heuristic calculation code - it looks reasonable at glance. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9741 From coleenp at openjdk.org Thu Aug 4 22:46:20 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Aug 2022 22:46:20 GMT Subject: RFR: 8290812: Add a test for ResourceHashtable [v8] In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 13:37:55 GMT, Coleen Phillimore wrote: >> I added a test for ResourceHashtable to show the interactions with it and Symbol* refcounting. >> Tested with tier1 on Oracle platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > More test cleanup Thanks for your suggested improvements, Ioi! ------------- PR: https://git.openjdk.org/jdk/pull/9603 From coleenp at openjdk.org Thu Aug 4 22:46:20 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Aug 2022 22:46:20 GMT Subject: Integrated: 8290812: Add a test for ResourceHashtable In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 20:22:58 GMT, Coleen Phillimore wrote: > I added a test for ResourceHashtable to show the interactions with it and Symbol* refcounting. > Tested with tier1 on Oracle platforms. This pull request has now been integrated. Changeset: 617a196f Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/617a196fd3b68c6958fa7198868b36fc0396b290 Stats: 160 lines in 1 file changed: 159 ins; 0 del; 1 mod 8290812: Add a test for ResourceHashtable Reviewed-by: stuefe, iklam ------------- PR: https://git.openjdk.org/jdk/pull/9603 From dlong at openjdk.org Fri Aug 5 02:38:49 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 5 Aug 2022 02:38:49 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v5] In-Reply-To: References: <5JfLyDDTi0H7WRva8W0WV7hI3xKvxVo7mPyaWzpx1pw=.a682010e-356f-4972-a343-a2058fa2b2ef@github.com> Message-ID: On Thu, 4 Aug 2022 15:06:22 GMT, Axel Boldt-Christmas wrote: >>> You are correct that nm should all be at least `unloading`, as if a klass is unloading all dependent `nmethods` should be unloading. So this code should boil down to: >>> >>> ```c++ >>> void DependencyContext::remove_all_dependents() { >>> nmethodBucket* b = dependencies_not_unloading(); >>> set_dependencies(NULL); >>> assert(b == nullptr, "All dependents should be unloading"); >>> } >>> ``` >>> >>> As `dependencies_not_unloading()` will unlink and release every dependent that is `unloading`. Have run stress tests on that change and no violations were found. Will push and test this change. >> >> From testing this seems not to be the case. Will investigate some more. So there are dependents that do no become `unloading` when the klass unloads. > > I would like to find out more in detail what you want to ensure, or situation you are afraid that might occur. > > I've tried to investigate what types of dependent nmethods are not `unloading` when the the klass with a dependency is unloaded. I suspect it has to do with class loading and compilation order. From what I understand the nmethod will only be unloading if it has a reference to a dead oop inside it. So the compiler must generate code which is dependent without having an oop baked in. > > I do find it difficult to reason about the lifetime of these dependencies (at least the logical part, the release, purge cycle of the memory seems pretty straight forward) and nmethods (the sweeper removal does make the nmethod lifecycle a lot easier to reason about tough). > > I am really interested in what you think. As this change is just always running an edge case which can happen in mainline. This just makes it default. Hotspot seems to have relied on this interaction being this way for some time. > > The windows machines finally woke up and the patch passed tier 1-7 My concern was that we could be removing the dependencies from nmethods that are still using them. But if that was the case, the old code would have the same problem. ------------- PR: https://git.openjdk.org/jdk/pull/9713 From dlong at openjdk.org Fri Aug 5 02:45:50 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 5 Aug 2022 02:45:50 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 20:42:59 GMT, Erik ?sterlund wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: >> >> - Add assertions >> - Fix marked logic >> - Erik refactorings > > Also, in DeoptimizationContext::deopt_compiled_methods, the SweeperBlocker completely blocks out the sweeper from running. But as I mentioned, even without that, without safepoint checks, we can never flush these things. > It's worth mentioning that there used to be a special case for OSR nmethods that they could be flushed immediately and skip the zombie step. But I removed that a few tears ago so we wouldn't have to think about that pathological case separately. @fisk, is there any chance that in the future we might figure out how to allow nmethods to be flushed without a safepoint? Maybe with handshakes or some other clever improvement? If no, then maybe a comment saying so would help. If yes, then are there some asserts we could add that would catch such a change? ------------- PR: https://git.openjdk.org/jdk/pull/9655 From iklam at openjdk.org Fri Aug 5 03:44:44 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 5 Aug 2022 03:44:44 GMT Subject: RFR: 8291945: Add OSInfo API for static OS information Message-ID: As suggested by @tstuefe in the review of #9600, many of the `os` APIs simply return a value that was initialized during VM start up. E.g., `os::vm_page_size()`. I have added a new class `OSInfo` for managing such info - Simplifies the per-OS implementation - Make the "init-only-once" check consistent - In some cases, the simpler `OSInfo` class can be used in lieu of the more complex `os` class. This improves HotSpot build time (e.g., relocInfo.hpp). Note: I moved only 2 fields in this PR as a first step. If this works well I plan to move more fields in the future. ------------- Commit messages: - fixed zero build; added comments - 8291945: Add OSInfo API for static OS information Changes: https://git.openjdk.org/jdk/pull/9758/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9758&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291945 Stats: 213 lines in 17 files changed: 108 ins; 68 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/9758.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9758/head:pull/9758 PR: https://git.openjdk.org/jdk/pull/9758 From dholmes at openjdk.org Fri Aug 5 04:00:48 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 5 Aug 2022 04:00:48 GMT Subject: RFR: 8291459: JVM crash with GenerateOopMap::error_work(char const*, __va_list_tag*) [v2] In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 17:18:16 GMT, Harold Seigel wrote: >> The JVM fails when generating oop maps for method getAlphanumericCode(int) in bug_file/com/google/zxing/qrcode/encoder/Encoder.javap because the last bytecode in the method is an unreachable conditional branch at byecode index 11131: >> >> 11124: ireturn >> 11125: iinc 41, 1 >> 11128: iload 41 >> 11130: iconst_2 >> 11131: if_icmple 291 >> >> The class file (Encoder.class) containing getAlphanumericCode(int) has a class file version of 49. So it is verified by the old verifier, which allows methods to end in a conditional branch provided that the conditional branch is unreachable during method execution. >> >> This fix changes GenerateOopMap::jump_targets_do() to handle such methods. >> >> The fix was tested by running the user's failing program, the new regression test, Mach5 tiers 1-2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linu x64, and the JC Lang,VM, and API tests locally on Linux x64. >> >> Please review. >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > remove CreateCodedumpOnCrash option Seems reasonable. One query on the test but nothing important. Surprised this has not been detected in the past. Thanks. test/hotspot/jtreg/runtime/GenerateOopMap/TestGenerateOopMapCrash.java line 34: > 32: */ > 33: > 34: package compiler.linkage; Why a package, and why this package for a runtime test ?? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9745 From dholmes at openjdk.org Fri Aug 5 04:20:45 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 5 Aug 2022 04:20:45 GMT Subject: RFR: 8291945: Add OSInfo API for static OS information In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 23:18:35 GMT, Ioi Lam wrote: > As suggested by @tstuefe in the review of #9600, many of the `os` APIs simply return a value that was initialized during VM start up. E.g., `os::vm_page_size()`. I have added a new class `OSInfo` for managing such info > > - Simplifies the per-OS implementation > - Make the "init-only-once" check consistent > - In some cases, the simpler `OSInfo` class can be used in lieu of the more complex `os` class. This improves HotSpot build time (e.g., relocInfo.hpp). > > Note: I moved only 2 fields in this PR as a first step. If this works well I plan to move more fields in the future. Seems reasonable, but I initially expected to see the os:: API removed and replaced by the OSInfo:: API, rather than OSInfo just being an internal implementation detail. src/hotspot/share/runtime/osInfo.hpp line 31: > 29: #include "utilities/debug.hpp" > 30: > 31: // Static information about the operation system. Initialized exactly once s/operation/operating src/hotspot/share/runtime/stackValue.hpp line 32: > 30: > 31: class BasicLock; > 32: class frame; Seems unrelated to this change. ?/ ------------- PR: https://git.openjdk.org/jdk/pull/9758 From iklam at openjdk.org Fri Aug 5 04:57:45 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 5 Aug 2022 04:57:45 GMT Subject: RFR: 8291945: Add OSInfo API for static OS information In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 04:13:12 GMT, David Holmes wrote: >> As suggested by @tstuefe in the review of #9600, many of the `os` APIs simply return a value that was initialized during VM start up. E.g., `os::vm_page_size()`. I have added a new class `OSInfo` for managing such info >> >> - Simplifies the per-OS implementation >> - Make the "init-only-once" check consistent >> - In some cases, the simpler `OSInfo` class can be used in lieu of the more complex `os` class. This improves HotSpot build time (e.g., relocInfo.hpp). >> >> Note: I moved only 2 fields in this PR as a first step. If this works well I plan to move more fields in the future. > > src/hotspot/share/runtime/stackValue.hpp line 32: > >> 30: >> 31: class BasicLock; >> 32: class frame; > > Seems unrelated to this change. ?/ This file was indirectly including frame.hpp via os.hpp. Since I removed os.hpp from this file, I needed to add a declaration for the `frame` class. ------------- PR: https://git.openjdk.org/jdk/pull/9758 From iklam at openjdk.org Fri Aug 5 05:01:44 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 5 Aug 2022 05:01:44 GMT Subject: RFR: 8291945: Add OSInfo API for static OS information In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 04:17:24 GMT, David Holmes wrote: > Seems reasonable, but I initially expected to see the os:: API removed and replaced by the OSInfo:: API, rather than OSInfo just being an internal implementation detail. I left os::vm_page_size() because: - It's used by a lot of places. I don't want this PR to be overwhelmed by such changes. - os::vm_page_size() is often used together with other os::xxx functions related to memory allocation. So at this point, OSInfo is a just lower-level API if you just want to find out the value of some OS parameters. So far I've used it in two popular headers to avoid including os.hpp ------------- PR: https://git.openjdk.org/jdk/pull/9758 From dholmes at openjdk.org Fri Aug 5 05:05:55 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 5 Aug 2022 05:05:55 GMT Subject: RFR: 8291945: Add OSInfo API for static OS information In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 04:54:02 GMT, Ioi Lam wrote: >> src/hotspot/share/runtime/stackValue.hpp line 32: >> >>> 30: >>> 31: class BasicLock; >>> 32: class frame; >> >> Seems unrelated to this change. ?/ > > This file was indirectly including frame.hpp via os.hpp. Since I removed os.hpp from this file, I needed to add a declaration for the `frame` class. I don't see any such removal in this file. ?? ------------- PR: https://git.openjdk.org/jdk/pull/9758 From dholmes at openjdk.org Fri Aug 5 05:09:54 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 5 Aug 2022 05:09:54 GMT Subject: RFR: 8291945: Add OSInfo API for static OS information In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 23:18:35 GMT, Ioi Lam wrote: > As suggested by @tstuefe in the review of #9600, many of the `os` APIs simply return a value that was initialized during VM start up. E.g., `os::vm_page_size()`. I have added a new class `OSInfo` for managing such info > > - Simplifies the per-OS implementation > - Make the "init-only-once" check consistent > - In some cases, the simpler `OSInfo` class can be used in lieu of the more complex `os` class. This improves HotSpot build time (e.g., relocInfo.hpp). > > Note: I moved only 2 fields in this PR as a first step. If this works well I plan to move more fields in the future. Marked as reviewed by dholmes (Reviewer). Okay I think it would be good to switch to the OSInfo API in the future, so that we reduce the scope of os even further and more clearly delineate an API to request services from the OS, and a simple query API for the OS. ------------- PR: https://git.openjdk.org/jdk/pull/9758 From iklam at openjdk.org Fri Aug 5 05:14:52 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 5 Aug 2022 05:14:52 GMT Subject: RFR: 8291945: Add OSInfo API for static OS information In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 05:02:04 GMT, David Holmes wrote: >> This file was indirectly including frame.hpp via os.hpp. Since I removed os.hpp from this file, I needed to add a declaration for the `frame` class. > > I don't see any such removal in this file. ?? Oh I was mistaken. What I did was removing os.hpp from relocInfo.hpp and safepointMechanismhpp. This exposed the fact that stackValue.hpp was using the `frame` class without a proper declaration. ------------- PR: https://git.openjdk.org/jdk/pull/9758 From eosterlund at openjdk.org Fri Aug 5 05:56:45 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 5 Aug 2022 05:56:45 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 20:42:59 GMT, Erik ?sterlund wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: >> >> - Add assertions >> - Fix marked logic >> - Erik refactorings > > Also, in DeoptimizationContext::deopt_compiled_methods, the SweeperBlocker completely blocks out the sweeper from running. But as I mentioned, even without that, without safepoint checks, we can never flush these things. > It's worth mentioning that there used to be a special case for OSR nmethods that they could be flushed immediately and skip the zombie step. But I removed that a few tears ago so we wouldn't have to think about that pathological case separately. > @fisk, is there any chance that in the future we might figure out how to allow nmethods to be flushed without a safepoint? Maybe with handshakes or some other clever improvement? If no, then maybe a comment saying so would help. If yes, then are there some asserts we could add that would catch such a change? Yes. With concurrent class unloading, nmethods are unloaded during concurrent execution. After the sweeper removal, this is done in 2 phases: 1. We unlink() the nmethod 2. A thread-local handshake with all JavaThreads (who might have gotten a reference to it before unlinking) 3. We flush() the nmethod ------------- PR: https://git.openjdk.org/jdk/pull/9655 From eosterlund at openjdk.org Fri Aug 5 05:56:49 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 5 Aug 2022 05:56:49 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: References: <82sPWKCNk4Jv-AkG0DeM2_tklUOqnFoa0sQ-HT_-gAs=.64921f41-6858-4c9d-b430-e648f39c56ae@github.com> <4EL9HeQWuevMHWXimhtoYzsbnaKlBMYXk5pAxwZzhr0=.1780faec-2785-40e8-abf6-cfccf7715323@github.com> Message-ID: <7NbAHvFX62POrIcnxB5OVoTpLH2QX0PMYwfTSx7-QuE=.913bfc5a-8fc1-4cce-975d-27c870316f8d@github.com> On Thu, 4 Aug 2022 22:14:37 GMT, Vladimir Kozlov wrote: >>> Initial review of few `code/` files. Will do more later. >>> >>> I am not comfortable with name `unloading` for this process because historically, for me, it is associated with class unloading and "unloading" corresponding nmethods. `cleaning` is more similar with `sweeping`. But it could be only me. >> >> Thanks for reviewing this change! I'm using the term "code cache unloading", because that is what we have always called unloading of nmethods triggered by the GC. And now it is the GC that owns this completely, so code cache unloading is the way in which nmethods are freed. At least that was my reasoning. I'd like to split the "unloading" parts of the CodeCache to a separate file, but I decided it's better to do that in a separate patch, as this patch is large enough and I don't want to move around code as well in it. Hope this makes sense. > >> > Initial review of few `code/` files. Will do more later. >> > I am not comfortable with name `unloading` for this process because historically, for me, it is associated with class unloading and "unloading" corresponding nmethods. `cleaning` is more similar with `sweeping`. But it could be only me. >> >> Thanks for reviewing this change! I'm using the term "code cache unloading", because that is what we have always called unloading of nmethods triggered by the GC. And now it is the GC that owns this completely, so code cache unloading is the way in which nmethods are freed. At least that was my reasoning. I'd like to split the "unloading" parts of the CodeCache to a separate file, but I decided it's better to do that in a separate patch, as this patch is large enough and I don't want to move around code as well in it. Hope this makes sense. > > Okay, I agree since it is GC operation now. Thanks for the review @vnkozlov ------------- PR: https://git.openjdk.org/jdk/pull/9741 From fyang at openjdk.org Fri Aug 5 06:50:31 2022 From: fyang at openjdk.org (Fei Yang) Date: Fri, 5 Aug 2022 06:50:31 GMT Subject: RFR: 8291952: riscv: Remove PRAGMA_NONNULL_IGNORED Message-ID: This is similar to: https://bugs.openjdk.org/browse/JDK-8291895 Because the bug that was warned about has now been fixed, the warnings are now superfluous. Build with GCC 11.2.0. ------------- Commit messages: - 8291952: riscv: Remove PRAGMA_NONNULL_IGNORED Changes: https://git.openjdk.org/jdk/pull/9766/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9766&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291952 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9766.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9766/head:pull/9766 PR: https://git.openjdk.org/jdk/pull/9766 From yadongwang at openjdk.org Fri Aug 5 06:50:31 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Fri, 5 Aug 2022 06:50:31 GMT Subject: RFR: 8291952: riscv: Remove PRAGMA_NONNULL_IGNORED In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 06:42:34 GMT, Fei Yang wrote: > This is similar to: https://bugs.openjdk.org/browse/JDK-8291895 > Because the bug that was warned about has now been fixed, the warnings are now superfluous. > Build with GCC 11.2.0. lgtm ------------- Marked as reviewed by yadongwang (Author). PR: https://git.openjdk.org/jdk/pull/9766 From duke at openjdk.org Fri Aug 5 07:13:47 2022 From: duke at openjdk.org (Johannes Bechberger) Date: Fri, 5 Aug 2022 07:13:47 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: <3tgDyKLzqlYnLTulogeM3emB5jACSvlRe52BzfOKebw=.7cef7288-0bf0-4802-bc20-6358755ff3e3@github.com> References: <5spIPfilTUt_4eoKTNReCYUFwJOuMJEaG7_s1nQ6eFU=.2023cfdd-9c5d-4d85-8da2-263bfe2b2bcf@github.com> <3tgDyKLzqlYnLTulogeM3emB5jACSvlRe52BzfOKebw=.7cef7288-0bf0-4802-bc20-6358755ff3e3@github.com> Message-ID: On Thu, 4 Aug 2022 11:57:39 GMT, Ludovic Henry wrote: >> Thanks for the review, @stefank > > Hi @fisk, thanks for the amazing cleanup! We've had a bunch of issues with the code sweeper and AsyncGetCallTrace with trying to unwind from dead code blobs (or what looked like it at least). Have you run some stress tests for AsyncGetCallTrace and this change? It may be something we can look into to make sure it doesn't increase the chances of crashes, or even reduces the chances of crashes. CC @jbachorik @parttimenerd > @luhenry @fisk I'm going to stress test it with my [jdk-profiling-tester](https://github.com/parttimenerd/jdk-profiling-tester) on M1 and x86 over night (comparing it with the current master). My script is unable to find any crashes (in both JDK builds on both platforms) which is good for AsyncProfiler users but bad for the overall use of my tester. I'll have to investigate that. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From kbarrett at openjdk.org Fri Aug 5 07:26:32 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 5 Aug 2022 07:26:32 GMT Subject: RFR: 8291953: Remove PTR32_FORMAT macros Message-ID: <-TXDFBzwdE1FCzfLAryFXjBWh4DlJCOQ7uWbUagUwfs=.2450b036-3dfd-4b04-865f-bb1689e5e4e8@github.com> Please review this change to remove the PTR32_FORMAT macro. And the idea of hard-coded 32bit pointers is bad; we already have the PTR_FORMAT macros that deal with the 32/64bit distinction for pointers, and those should be used for such. However, all uses of PTR32_FORMAT are actually with values that are real uint values, not (converted) pointers. They should just use "%u" instead. So we can eliminate PTR32_FORMAT. The unused PTR32_FORMAT_W is is also removed. Testing: mach5 tier1 ------------- Commit messages: - remove PTR32_FORMAT Changes: https://git.openjdk.org/jdk/pull/9768/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9768&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291953 Stats: 12 lines in 3 files changed: 0 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9768.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9768/head:pull/9768 PR: https://git.openjdk.org/jdk/pull/9768 From shade at openjdk.org Fri Aug 5 07:32:46 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 5 Aug 2022 07:32:46 GMT Subject: RFR: 8291952: riscv: Remove PRAGMA_NONNULL_IGNORED In-Reply-To: References: Message-ID: <_G3wm9XvdVd_VDoY74ejCRCAg5ledEQTFvDNyJF2tmQ=.d9c0ca04-c629-4a42-88d0-cc765be2acf7@github.com> On Fri, 5 Aug 2022 06:42:34 GMT, Fei Yang wrote: > This is similar to: https://bugs.openjdk.org/browse/JDK-8291895 > Because the bug that was warned about has now been fixed, the warnings are now superfluous. > Build with GCC 11.2.0. Looks fine. Can you link the issue that fixes the underlying issue to this bug? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9766 From shade at openjdk.org Fri Aug 5 07:33:51 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 5 Aug 2022 07:33:51 GMT Subject: RFR: 8291953: Remove PTR32_FORMAT macros In-Reply-To: <-TXDFBzwdE1FCzfLAryFXjBWh4DlJCOQ7uWbUagUwfs=.2450b036-3dfd-4b04-865f-bb1689e5e4e8@github.com> References: <-TXDFBzwdE1FCzfLAryFXjBWh4DlJCOQ7uWbUagUwfs=.2450b036-3dfd-4b04-865f-bb1689e5e4e8@github.com> Message-ID: On Fri, 5 Aug 2022 07:19:13 GMT, Kim Barrett wrote: > Please review this change to remove the PTR32_FORMAT macro. > > And the idea of hard-coded 32bit pointers is bad; we already have the > PTR_FORMAT macros that deal with the 32/64bit distinction for pointers, and > those should be used for such. > > However, all uses of PTR32_FORMAT are actually with values that are real uint > values, not (converted) pointers. They should just use "%u" instead. So we > can eliminate PTR32_FORMAT. > > The unused PTR32_FORMAT_W is is also removed. > > Testing: > mach5 tier1 Good riddance. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9768 From eosterlund at openjdk.org Fri Aug 5 07:51:13 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 5 Aug 2022 07:51:13 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: <3tgDyKLzqlYnLTulogeM3emB5jACSvlRe52BzfOKebw=.7cef7288-0bf0-4802-bc20-6358755ff3e3@github.com> References: <5spIPfilTUt_4eoKTNReCYUFwJOuMJEaG7_s1nQ6eFU=.2023cfdd-9c5d-4d85-8da2-263bfe2b2bcf@github.com> <3tgDyKLzqlYnLTulogeM3emB5jACSvlRe52BzfOKebw=.7cef7288-0bf0-4802-bc20-6358755ff3e3@github.com> Message-ID: On Thu, 4 Aug 2022 11:57:39 GMT, Ludovic Henry wrote: >> Thanks for the review, @stefank > > Hi @fisk, thanks for the amazing cleanup! We've had a bunch of issues with the code sweeper and AsyncGetCallTrace with trying to unwind from dead code blobs (or what looked like it at least). Have you run some stress tests for AsyncGetCallTrace and this change? It may be something we can look into to make sure it doesn't increase the chances of crashes, or even reduces the chances of crashes. CC @jbachorik @parttimenerd > > @luhenry @fisk I'm going to stress test it with my [jdk-profiling-tester](https://github.com/parttimenerd/jdk-profiling-tester) on M1 and x86 over night (comparing it with the current master). > > > > My script is unable to find any crashes (in both JDK builds on both platforms) which is good for AsyncProfiler users but bad for the overall use of my tester. I'll have to investigate that. Thank you for taking this for a spin. I'm glad it isn't crashing more. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From fyang at openjdk.org Fri Aug 5 07:54:19 2022 From: fyang at openjdk.org (Fei Yang) Date: Fri, 5 Aug 2022 07:54:19 GMT Subject: RFR: 8291952: riscv: Remove PRAGMA_NONNULL_IGNORED In-Reply-To: <_G3wm9XvdVd_VDoY74ejCRCAg5ledEQTFvDNyJF2tmQ=.d9c0ca04-c629-4a42-88d0-cc765be2acf7@github.com> References: <_G3wm9XvdVd_VDoY74ejCRCAg5ledEQTFvDNyJF2tmQ=.d9c0ca04-c629-4a42-88d0-cc765be2acf7@github.com> Message-ID: On Fri, 5 Aug 2022 07:30:40 GMT, Aleksey Shipilev wrote: > Looks fine. Can you link the issue that fixes the underlying issue to this bug? Sure, I have added the link. Thanks all for the quick review. ------------- PR: https://git.openjdk.org/jdk/pull/9766 From fyang at openjdk.org Fri Aug 5 07:54:19 2022 From: fyang at openjdk.org (Fei Yang) Date: Fri, 5 Aug 2022 07:54:19 GMT Subject: Integrated: 8291952: riscv: Remove PRAGMA_NONNULL_IGNORED In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 06:42:34 GMT, Fei Yang wrote: > This is similar to: https://bugs.openjdk.org/browse/JDK-8291895 > Because the bug that was warned about has now been fixed, the warnings are now superfluous. > Build with GCC 11.2.0. This pull request has now been integrated. Changeset: 4c652d9e Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/4c652d9ecace0d07eed43fd11678238707f948de Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod 8291952: riscv: Remove PRAGMA_NONNULL_IGNORED Reviewed-by: yadongwang, shade ------------- PR: https://git.openjdk.org/jdk/pull/9766 From duke at openjdk.org Fri Aug 5 07:58:52 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Fri, 5 Aug 2022 07:58:52 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 20:57:06 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Feedback v2 src/hotspot/share/oops/methodCounters.hpp line 42: > 40: jlong _prev_time; // Previous time the rate was acquired > 41: float _rate; // Events (invocation and backedge counter increments) per millisecond > 42: int _nmethod_age; Stale comment below. ```C++ // NMethod age is a counter for warm methods detection in the code cache sweeper. // [...] ------------- PR: https://git.openjdk.org/jdk/pull/9741 From stefank at openjdk.org Fri Aug 5 07:59:58 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 5 Aug 2022 07:59:58 GMT Subject: RFR: 8291953: Remove PTR32_FORMAT macros In-Reply-To: <-TXDFBzwdE1FCzfLAryFXjBWh4DlJCOQ7uWbUagUwfs=.2450b036-3dfd-4b04-865f-bb1689e5e4e8@github.com> References: <-TXDFBzwdE1FCzfLAryFXjBWh4DlJCOQ7uWbUagUwfs=.2450b036-3dfd-4b04-865f-bb1689e5e4e8@github.com> Message-ID: On Fri, 5 Aug 2022 07:19:13 GMT, Kim Barrett wrote: > Please review this change to remove the PTR32_FORMAT macro. > > And the idea of hard-coded 32bit pointers is bad; we already have the > PTR_FORMAT macros that deal with the 32/64bit distinction for pointers, and > those should be used for such. > > However, all uses of PTR32_FORMAT are actually with values that are real uint > values, not (converted) pointers. They should just use "%u" instead. So we > can eliminate PTR32_FORMAT. > > The unused PTR32_FORMAT_W is is also removed. > > Testing: > mach5 tier1 Wouldn't it be more appropriate to change this to bring hex values instead? I guess that was the original intention of using a PTR format specifier. Also, are you going to remove the PTR64_FORMAT as well? ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.org/jdk/pull/9768 From eosterlund at openjdk.org Fri Aug 5 08:17:51 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 5 Aug 2022 08:17:51 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v5] In-Reply-To: References: <5JfLyDDTi0H7WRva8W0WV7hI3xKvxVo7mPyaWzpx1pw=.a682010e-356f-4972-a343-a2058fa2b2ef@github.com> Message-ID: On Fri, 5 Aug 2022 02:34:49 GMT, Dean Long wrote: >> I would like to find out more in detail what you want to ensure, or situation you are afraid that might occur. >> >> I've tried to investigate what types of dependent nmethods are not `unloading` when the the klass with a dependency is unloaded. I suspect it has to do with class loading and compilation order. From what I understand the nmethod will only be unloading if it has a reference to a dead oop inside it. So the compiler must generate code which is dependent without having an oop baked in. >> >> I do find it difficult to reason about the lifetime of these dependencies (at least the logical part, the release, purge cycle of the memory seems pretty straight forward) and nmethods (the sweeper removal does make the nmethod lifecycle a lot easier to reason about tough). >> >> I am really interested in what you think. As this change is just always running an edge case which can happen in mainline. This just makes it default. Hotspot seems to have relied on this interaction being this way for some time. >> >> The windows machines finally woke up and the patch passed tier 1-7 > > My concern was that we could be removing the dependencies from nmethods that are still using them. But if that was the case, the old code would have the same problem. The compiler dependencies are protecting against loading of a class that is a subtype of X. If X is unloaded, then we can be pretty sure nobody is going to load a subclass of X. ------------- PR: https://git.openjdk.org/jdk/pull/9713 From duke at openjdk.org Fri Aug 5 08:19:48 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Fri, 5 Aug 2022 08:19:48 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 20:57:06 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Feedback v2 There are a few comments that mention the sweeper as well. * `src/hotspot/share/jvmci/jvmci.hpp:110` * `CodeInstallResult::nmethod_reclaimed` enum * This seems like it is dead code now, there does not look like there is any safepoint between the creation of the `nmethod` and the call to `make_in_use()` so it should return true always? Not looked to close at it. But regardless, feels like it should be at least noted that the `JVMCIRuntime::register_method` function should be looked at by someone in the future. * `src/hotspot/share/gc/shared/space.cpp:147` * Old code, maybe just the reference to the sweeper can be removed. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From duke at openjdk.org Fri Aug 5 08:27:06 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Fri, 5 Aug 2022 08:27:06 GMT Subject: Integrated: 8290090: Change CodeBlobType from unscoped enum to enum class In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 07:55:49 GMT, Axel Boldt-Christmas wrote: > Change: > ```C++ > struct CodeBlobType { > enum { [...] } > } > > To: > ```C++ > enum class CodeBlobType { > [...] > }; > > Using C++11 scoped enums provides a more clear view of intent, as enums can be enforced by the type system instead of being passed around as ints. > > Testing: Tier 1-3 This pull request has now been integrated. Changeset: dd7f2d91 Author: Axel Boldt-Christmas Committer: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/dd7f2d912bb66c0f10d7165040e52e2d18b73897 Stats: 78 lines in 11 files changed: 7 ins; 4 del; 67 mod 8290090: Change CodeBlobType from unscoped enum to enum class Reviewed-by: eosterlund, kvn ------------- PR: https://git.openjdk.org/jdk/pull/9460 From eosterlund at openjdk.org Fri Aug 5 08:32:20 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 5 Aug 2022 08:32:20 GMT Subject: RFR: 8290025: Remove the Sweeper [v4] In-Reply-To: References: Message-ID: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Remove incorrect comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9741/files - new: https://git.openjdk.org/jdk/pull/9741/files/331ad2f7..691093d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9741/head:pull/9741 PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Fri Aug 5 08:32:20 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 5 Aug 2022 08:32:20 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: References: Message-ID: <9vXuPHBKlazCA5QT1EOsCUCT18fmJXWCcpY1VZA1YO8=.3ecec4c9-ddb9-495c-8289-c5872db9a3c5@github.com> On Fri, 5 Aug 2022 08:16:10 GMT, Axel Boldt-Christmas wrote: > There are a few comments that mention the sweeper as well. > > * `src/hotspot/share/jvmci/jvmci.hpp:110` > > * `CodeInstallResult::nmethod_reclaimed` enum > > * This seems like it is dead code now, there does not look like there is any safepoint between the creation of the `nmethod` and the call to `make_in_use()` so it should return true always? Not looked to close at it. But regardless, feels like it should be at least noted that the `JVMCIRuntime::register_method` function should be looked at by someone in the future. I removed the comment. It isn't dead code, nmethods can still be made not_entrant before being installed. Just not by the sweeper. > * `src/hotspot/share/gc/shared/space.cpp:147` > > * Old code, maybe just the reference to the sweeper can be removed. This is referring to the sweeping part of the mark and sweep algorithm. CMS (Concurrent Mark Sweep) did sweeping concurrently. It's a different thing. One might argue the comment should go, but not in this patch. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From yadongwang at openjdk.org Fri Aug 5 09:45:37 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Fri, 5 Aug 2022 09:45:37 GMT Subject: RFR: 8291893: riscv: remove fence.i used in user space Message-ID: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> The usage of fence.i is in-efficient or redundant in the current implementation of riscv port now. The riscv port has already followed the [RISC-V platform specification](https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc): the write hart use the __builtin__clear_cache or the syscall riscv_flush_icache directly after modifying code in riscv port, to execute fence.i on local hart and other harts by IPI. That's because fence.i only synchronizes the local hart, and the OS can reschedule the user hart to a different physical hart after the fence.i. "To order older stores before younger instruction fetches, user-level programs must use system supplied library calls (e.g. GNU libc's __riscv_flush_icache, which invokes the Linux kernel's corresponding vDSO routine), rather than executing the fence.i instruction directly." What now seems unnecessary is that we also put fence.i in front of code that will be modifed concurrently, just like Aarch64 port. Because the icache flush syscall already provides the explicit icache synchronization between all harts, so that we can remove fence.i used in the read hart. Details of the discussion can be found in https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000571.html. In contrast, the isb in aarch64 is not broadcast by the writing PE, so any other PE must perform its own isb synchronization after it knows that the instruction update is visible. Tier1 of hotspot and jdk passed on unmatched. ------------- Commit messages: - 8291893: riscv: remove fence.i used in user space Changes: https://git.openjdk.org/jdk/pull/9770/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9770&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291893 Stats: 68 lines in 9 files changed: 0 ins; 62 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9770.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9770/head:pull/9770 PR: https://git.openjdk.org/jdk/pull/9770 From eosterlund at openjdk.org Fri Aug 5 10:00:14 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 5 Aug 2022 10:00:14 GMT Subject: RFR: 8290025: Remove the Sweeper [v5] In-Reply-To: References: Message-ID: <-cQs2Xuq_DOjFYt7QwtuZyYFxuqADo42rwIqAVT9-2w=.72d2bc53-3f27-471a-8c64-df7a6a391b6c@github.com> > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Removed more stale things ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9741/files - new: https://git.openjdk.org/jdk/pull/9741/files/691093d0..814fdd4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=03-04 Stats: 13 lines in 2 files changed: 0 ins; 13 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9741/head:pull/9741 PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Fri Aug 5 10:10:28 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 5 Aug 2022 10:10:28 GMT Subject: RFR: 8290025: Remove the Sweeper [v6] In-Reply-To: References: Message-ID: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Erik ?sterlund 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 8290025_remove_sweeper - Removed more stale things - Remove incorrect comment - Feedback v2 - Feedback v1 - 8290025: Remove the Sweeper ------------- Changes: https://git.openjdk.org/jdk/pull/9741/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=05 Stats: 4107 lines in 187 files changed: 557 ins; 2983 del; 567 mod Patch: https://git.openjdk.org/jdk/pull/9741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9741/head:pull/9741 PR: https://git.openjdk.org/jdk/pull/9741 From kim.barrett at oracle.com Fri Aug 5 11:36:04 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 5 Aug 2022 11:36:04 +0000 Subject: RFR: 8291953: Remove PTR32_FORMAT macros In-Reply-To: References: <-TXDFBzwdE1FCzfLAryFXjBWh4DlJCOQ7uWbUagUwfs=.2450b036-3dfd-4b04-865f-bb1689e5e4e8@github.com> Message-ID: <93192C6B-4093-48B5-96DB-581BEB4FD026@oracle.com> > On Aug 5, 2022, at 3:59 AM, Stefan Karlsson wrote: > > On Fri, 5 Aug 2022 07:19:13 GMT, Kim Barrett wrote: > >> Please review this change to remove the PTR32_FORMAT macro. >> >> And the idea of hard-coded 32bit pointers is bad; we already have the >> PTR_FORMAT macros that deal with the 32/64bit distinction for pointers, and >> those should be used for such. >> >> However, all uses of PTR32_FORMAT are actually with values that are real uint >> values, not (converted) pointers. They should just use "%u" instead. So we >> can eliminate PTR32_FORMAT. >> >> The unused PTR32_FORMAT_W is is also removed. >> >> Testing: >> mach5 tier1 > > Wouldn't it be more appropriate to change this to bring hex values instead? I guess that was the original intention of using a PTR format specifier. Shoot, they?re supposed to be hex! Bleh! > Also, are you going to remove the PTR64_FORMAT as well? Probably, but uses of it are more of a mixed bag. Some are dealing with pointers (converted via p2i) and some are dealing with [u]int64_t and should be using some other xxx_FORMAT entirely (or perhaps one of the new C99 directives). From duke at openjdk.org Fri Aug 5 12:24:00 2022 From: duke at openjdk.org (David Schlosnagle) Date: Fri, 5 Aug 2022 12:24:00 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 20:57:06 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Feedback v2 src/hotspot/share/code/codeCache.cpp line 714: > 712: size_t max = max_capacity(); > 713: size_t used = max - free; > 714: double gc_interval = time - last_time; Are `gc_interval` and `duration` both needed? They seem duplicative. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From kbarrett at openjdk.org Fri Aug 5 12:40:55 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 5 Aug 2022 12:40:55 GMT Subject: RFR: 8291953: Remove PTR32_FORMAT macros In-Reply-To: <-TXDFBzwdE1FCzfLAryFXjBWh4DlJCOQ7uWbUagUwfs=.2450b036-3dfd-4b04-865f-bb1689e5e4e8@github.com> References: <-TXDFBzwdE1FCzfLAryFXjBWh4DlJCOQ7uWbUagUwfs=.2450b036-3dfd-4b04-865f-bb1689e5e4e8@github.com> Message-ID: On Fri, 5 Aug 2022 07:19:13 GMT, Kim Barrett wrote: > Please review this change to remove the PTR32_FORMAT macro. > > And the idea of hard-coded 32bit pointers is bad; we already have the > PTR_FORMAT macros that deal with the 32/64bit distinction for pointers, and > those should be used for such. > > However, all uses of PTR32_FORMAT are actually with values that are real uint > values, not (converted) pointers. They should just use "%u" instead. So we > can eliminate PTR32_FORMAT. > > The unused PTR32_FORMAT_W is is also removed. > > Testing: > mach5 tier1 Closed as botched and need to rethink. ------------- PR: https://git.openjdk.org/jdk/pull/9768 From kbarrett at openjdk.org Fri Aug 5 12:40:55 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 5 Aug 2022 12:40:55 GMT Subject: Withdrawn: 8291953: Remove PTR32_FORMAT macros In-Reply-To: <-TXDFBzwdE1FCzfLAryFXjBWh4DlJCOQ7uWbUagUwfs=.2450b036-3dfd-4b04-865f-bb1689e5e4e8@github.com> References: <-TXDFBzwdE1FCzfLAryFXjBWh4DlJCOQ7uWbUagUwfs=.2450b036-3dfd-4b04-865f-bb1689e5e4e8@github.com> Message-ID: <_9mWUsmfmHF9QHGgL_xPND-1mziWxOi-zwtS6xoRo3M=.fd6de90e-b6df-4de8-80b7-6321f3eb48b7@github.com> On Fri, 5 Aug 2022 07:19:13 GMT, Kim Barrett wrote: > Please review this change to remove the PTR32_FORMAT macro. > > And the idea of hard-coded 32bit pointers is bad; we already have the > PTR_FORMAT macros that deal with the 32/64bit distinction for pointers, and > those should be used for such. > > However, all uses of PTR32_FORMAT are actually with values that are real uint > values, not (converted) pointers. They should just use "%u" instead. So we > can eliminate PTR32_FORMAT. > > The unused PTR32_FORMAT_W is is also removed. > > Testing: > mach5 tier1 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9768 From hseigel at openjdk.org Fri Aug 5 13:44:05 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Fri, 5 Aug 2022 13:44:05 GMT Subject: RFR: 8291459: JVM crash with GenerateOopMap::error_work(char const*, __va_list_tag*) [v3] In-Reply-To: References: Message-ID: > The JVM fails when generating oop maps for method getAlphanumericCode(int) in bug_file/com/google/zxing/qrcode/encoder/Encoder.javap because the last bytecode in the method is an unreachable conditional branch at byecode index 11131: > > 11124: ireturn > 11125: iinc 41, 1 > 11128: iload 41 > 11130: iconst_2 > 11131: if_icmple 291 > > The class file (Encoder.class) containing getAlphanumericCode(int) has a class file version of 49. So it is verified by the old verifier, which allows methods to end in a conditional branch provided that the conditional branch is unreachable during method execution. > > This fix changes GenerateOopMap::jump_targets_do() to handle such methods. > > The fix was tested by running the user's failing program, the new regression test, Mach5 tiers 1-2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linu x64, and the JC Lang,VM, and API tests locally on Linux x64. > > Please review. > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: remove packages from test classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9745/files - new: https://git.openjdk.org/jdk/pull/9745/files/4c72e190..fef2b43c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9745&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9745&range=01-02 Stats: 7 lines in 2 files changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9745.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9745/head:pull/9745 PR: https://git.openjdk.org/jdk/pull/9745 From hseigel at openjdk.org Fri Aug 5 13:44:06 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Fri, 5 Aug 2022 13:44:06 GMT Subject: RFR: 8291459: JVM crash with GenerateOopMap::error_work(char const*, __va_list_tag*) [v2] In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 03:54:27 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> remove CreateCodedumpOnCrash option > > test/hotspot/jtreg/runtime/GenerateOopMap/TestGenerateOopMapCrash.java line 34: > >> 32: */ >> 33: >> 34: package compiler.linkage; > > Why a package, and why this package for a runtime test ?? Commit 3 removed the packages. Thanks for pointing this out. ------------- PR: https://git.openjdk.org/jdk/pull/9745 From coleenp at openjdk.org Fri Aug 5 14:59:45 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 5 Aug 2022 14:59:45 GMT Subject: RFR: 8291970: Add TableStatistics get function to ResourceHashtable Message-ID: Add a statistics_calculate function to ResourceHashtable so that we can use it for printing. Also add a test. Tested with tier1 on Oracle platforms (with and without product build). ------------- Commit messages: - 8291970: Add TableStatistics get function to ResourceHashtable Changes: https://git.openjdk.org/jdk/pull/9775/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9775&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291970 Stats: 74 lines in 4 files changed: 71 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9775.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9775/head:pull/9775 PR: https://git.openjdk.org/jdk/pull/9775 From pchilanomate at openjdk.org Fri Aug 5 15:24:51 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 5 Aug 2022 15:24:51 GMT Subject: RFR: 8291972: Fix double copy of arguments when thawing two interpreted frames Message-ID: When thawing two consecutive interpreted frames the current code makes room in the stack and copies the callee arguments twice, once in the caller and once in the callee. This duplication could use more stack space than the calculation made in prepare_thaw() for the maximum stack space that will be needed during thaw. If that's the case then we will hit an assert that we are writing pass the allowed limit. Today we don't see this issue though because the only case where we could thaw two interpreter frames is the first time after a freeze. The thawed frames are always Continuation.yield and Continuation.yield0 and the extra used space is only 3 words(yield0's three arguments) which will never exceed the calculation made in prepare_thaw(). The issue can be made visible when changing the number of frames we thaw when hitting a return barrier from 1 to 2 and running test Continuation/Basic.java. This patch fixes this by adjusting the calculated size of the callee frame in new_stack_frame() so that we use the space for the arguments already allocated by the caller. Tested the patch by changing the number of thaw frames from 1 to 2 and running all tests in jdk/internal/vm/Continuation/ and jdk/java/lang/Thread/virtual. Also run tiers1-3 in mach5 and loom-tiers1-4. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/9774/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9774&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291972 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9774.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9774/head:pull/9774 PR: https://git.openjdk.org/jdk/pull/9774 From duke at openjdk.org Fri Aug 5 17:10:10 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Fri, 5 Aug 2022 17:10:10 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call Message-ID: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> `MacroAssembler::trampoline_call` can skip generation of a trampoline stub if C2 phase output is in the checking emitted code size mode. If it is not C2 compilation, `trampoline_call` always generates a trampoline stub. `gen_continuation_enter` as a part of C2 compilation needed to disable the functionality above. Now `trampoline_call` has the `check_emit_size` which allows to disable the functionality completely. Its default value is `true` which means the functionality is enabled. There are problems: - C2 specific code which must be properly guarded if it is not C2 compilation. The code has the risk of undefined behaviour (UB). It is done with `is_c2_compile`. [JDK-8291654](https://bugs.openjdk.org/browse/JDK-8291654) is an example of changes caused UB. - The default value of `check_emit_size`. The current value `true` allows C1 to access the C2 specific code. Setting the default value to `false` will require to review and to update every existing use of `trampoline_call`. It will complicate uses of `trampoline_call`: each time a decision needs to be done - use or not use the default. Summary of changes: - Have a virtual `emit_trampoline_stub` which is privately overridden in `C2_MacroAssembler`. The overridden version does not emit a stub if C2 phase output is in the checking emitted code size mode. - `emit_trampoline_stub` returns `bool` instead of `address` because `address` is only used to check the success of a call. - `check_emit_size` is removed because it is not needed any more. - `NativeCall::trampoline_jump`: - Changed to return `void` because the result is not used. It was returning the result of `emit_trampoline_stub`. - Assert `emit_trampoline_stub`. Tested with fastdebug/release builds: - `gtest`: Passed. - `tier1`...`tier4`: Passed. ------------- Commit messages: - 8291752: AArch64: Remove check_emit_size parameter from trampoline_call Changes: https://git.openjdk.org/jdk/pull/9782/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9782&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291752 Stats: 76 lines in 7 files changed: 30 ins; 25 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/9782.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9782/head:pull/9782 PR: https://git.openjdk.org/jdk/pull/9782 From duke at openjdk.org Fri Aug 5 17:13:32 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Fri, 5 Aug 2022 17:13:32 GMT Subject: RFR: 8291654: AArch64: assert from JDK-8287393 causes crashes In-Reply-To: <-5AB5hBjKTSdYs-n-xuptTTT3-3r8W1_RX44ARwg2lc=.b24ca7a9-4cab-47d8-a8da-010ac93ce02d@github.com> References: <-Pww2K5Wc10ygAnecPvz8js2lQQmoxjow20dDILXq7c=.77017e1a-c203-4ae4-9498-4a5b74aa1649@github.com> <-5AB5hBjKTSdYs-n-xuptTTT3-3r8W1_RX44ARwg2lc=.b24ca7a9-4cab-47d8-a8da-010ac93ce02d@github.com> Message-ID: <11PWZ3lrLEceAmgbUFX3Hw1nUmQkDgzi6Wck8QBIT7E=.d9b69bff-0436-46ed-b103-c5980d6e8279@github.com> On Tue, 2 Aug 2022 15:49:45 GMT, Vladimir Kozlov wrote: > > I can submit PR with it if there is interest in the solution. > > What do you think? > > @eastig Please do that. Your code change suggestion is good. @vnkozlov, @theRealAph I've created PR: https://github.com/openjdk/jdk/pull/9782 Could you have a look? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9709 From svkamath at openjdk.org Fri Aug 5 17:16:40 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Fri, 5 Aug 2022 17:16:40 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats Message-ID: 8289552: Make intrinsic conversions between bit representations of half precision values and floats ------------- Commit messages: - Intrinsic conversions between halffloat and floats Changes: https://git.openjdk.org/jdk/pull/9781/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289552 Stats: 220 lines in 13 files changed: 212 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9781.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781 PR: https://git.openjdk.org/jdk/pull/9781 From svkamath at openjdk.org Fri Aug 5 17:16:40 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Fri, 5 Aug 2022 17:16:40 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 16:36:23 GMT, Smita Kamath wrote: > 8289552: Make intrinsic conversions between bit representations of half precision values and floats Hi All, This change is to provide intrinsic implementation for conversion between floats and half precision floating point formats. Kindly review and share your feedback. Thanks, Smita ------------- PR: https://git.openjdk.org/jdk/pull/9781 From iveresov at openjdk.org Fri Aug 5 17:17:08 2022 From: iveresov at openjdk.org (Igor Veresov) Date: Fri, 5 Aug 2022 17:17:08 GMT Subject: RFR: 8290025: Remove the Sweeper [v6] In-Reply-To: References: Message-ID: <8o7uSqRhapk7Gtdel7lIfFBVfn7OA-nrMp4MLWncWXA=.2d2747ec-612b-47c9-a733-4f1826b73a17@github.com> On Fri, 5 Aug 2022 10:10:28 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund 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 8290025_remove_sweeper > - Removed more stale things > - Remove incorrect comment > - Feedback v2 > - Feedback v1 > - 8290025: Remove the Sweeper So in the new world do we always need a GC cycle to flush (as opposed to unload) an method? ------------- PR: https://git.openjdk.org/jdk/pull/9741 From kvn at openjdk.org Fri Aug 5 17:58:09 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 5 Aug 2022 17:58:09 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call In-Reply-To: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: On Fri, 5 Aug 2022 16:59:08 GMT, Evgeny Astigeevich wrote: > `MacroAssembler::trampoline_call` can skip generation of a trampoline stub if C2 phase output is in the checking emitted code size mode. If it is not C2 compilation, `trampoline_call` always generates a trampoline stub. > > `gen_continuation_enter` as a part of C2 compilation needed to disable the functionality above. Now `trampoline_call` has the `check_emit_size` which allows to disable the functionality completely. Its default value is `true` which means the functionality is enabled. > > There are problems: > - C2 specific code which must be properly guarded if it is not C2 compilation. The code has the risk of undefined behaviour (UB). It is done with `is_c2_compile`. [JDK-8291654](https://bugs.openjdk.org/browse/JDK-8291654) is an example of changes caused UB. > - The default value of `check_emit_size`. The current value `true` allows C1 to access the C2 specific code. Setting the default value to `false` will require to review and to update every existing use of `trampoline_call`. It will complicate uses of `trampoline_call`: each time a decision needs to be done - use or not use the default. > > Summary of changes: > - Have a virtual `emit_trampoline_stub` which is privately overridden in `C2_MacroAssembler`. The overridden version does not emit a stub if C2 phase output is in the checking emitted code size mode. > - `emit_trampoline_stub` returns `bool` instead of `address` because `address` is only used to check the success of a call. > - `check_emit_size` is removed because it is not needed any more. > - `NativeCall::trampoline_jump`: > - Changed to return `void` because the result is not used. It was returning the result of `emit_trampoline_stub`. > - Assert `emit_trampoline_stub`. > > Tested with fastdebug/release builds: > - `gtest`: Passed. > - `tier1`...`tier4`: Passed. I have few comments. src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1661: > 1659: bool C2_MacroAssembler::emit_trampoline_stub(int insts_call_instruction_offset, address target) { > 1660: if (ciEnv::current()->task() != NULL) { > 1661: assert(is_c2_compile(ciEnv::current()->task()->comp_level()), "not C2 compilation task"); You don't need this assert. `C2_MacroAssembler` is used only in `.ad` files used by C2 only. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 864: > 862: // We might need a trampoline if branches are far. > 863: bool need_trampoline = far_branches(); > 864: if (!need_trampoline && entry.rspec().type() == relocInfo::runtime_call_type && !CodeCache::contains(entry.target())) { In `CodeCache::contains(entry.target())` you can use `target` value. src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp line 541: > 539: // If we generated no stub, patch this call directly to dest. > 540: // This will happen if we don't need far branches or if there > 541: // already was a trampoline. I think this comment should be changed since you changed the code. ------------- PR: https://git.openjdk.org/jdk/pull/9782 From bulasevich at openjdk.org Fri Aug 5 18:19:06 2022 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Fri, 5 Aug 2022 18:19:06 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 20:20:53 GMT, Erik ?sterlund wrote: > It still might be that my new algorithm is more aggressive, but the data does not conclude that I tweaked JMH code to run Warmup iterations for all benchmarks first (a single vm run mode), and than run the final Iterations for the benchmarks (renaissance suite in my case). The idea is to check if a new sweeper algorithm flush the hot methods before the final iteration and get a performance penalty. I played with a benchmark set, combining them into different groups, changing the number of Warmup iterations and VM options. With this approach I do not find evidence that the new algorithm is more aggressive than the previous one. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From duke at openjdk.org Fri Aug 5 19:26:04 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Fri, 5 Aug 2022 19:26:04 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call In-Reply-To: References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: On Fri, 5 Aug 2022 17:53:28 GMT, Vladimir Kozlov wrote: >> `MacroAssembler::trampoline_call` can skip generation of a trampoline stub if C2 phase output is in the checking emitted code size mode. If it is not C2 compilation, `trampoline_call` always generates a trampoline stub. >> >> `gen_continuation_enter` as a part of C2 compilation needed to disable the functionality above. Now `trampoline_call` has the `check_emit_size` which allows to disable the functionality completely. Its default value is `true` which means the functionality is enabled. >> >> There are problems: >> - C2 specific code which must be properly guarded if it is not C2 compilation. The code has the risk of undefined behaviour (UB). It is done with `is_c2_compile`. [JDK-8291654](https://bugs.openjdk.org/browse/JDK-8291654) is an example of changes caused UB. >> - The default value of `check_emit_size`. The current value `true` allows C1 to access the C2 specific code. Setting the default value to `false` will require to review and to update every existing use of `trampoline_call`. It will complicate uses of `trampoline_call`: each time a decision needs to be done - use or not use the default. >> >> Summary of changes: >> - Have a virtual `emit_trampoline_stub` which is privately overridden in `C2_MacroAssembler`. The overridden version does not emit a stub if C2 phase output is in the checking emitted code size mode. >> - `emit_trampoline_stub` returns `bool` instead of `address` because `address` is only used to check the success of a call. >> - `check_emit_size` is removed because it is not needed any more. >> - `NativeCall::trampoline_jump`: >> - Changed to return `void` because the result is not used. It was returning the result of `emit_trampoline_stub`. >> - Assert `emit_trampoline_stub`. >> >> Tested with fastdebug/release builds: >> - `gtest`: Passed. >> - `tier1`...`tier4`: Passed. > > src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp line 541: > >> 539: // If we generated no stub, patch this call directly to dest. >> 540: // This will happen if we don't need far branches or if there >> 541: // already was a trampoline. > > I think this comment should be changed since you changed the code. The original code looks strange to me. If we need a stub but we have failed to create it, we set dest anyway. This will lead to an incorrect instruction. The behaviour is undefined. We might fail executing the instruction or jump somewhere. ------------- PR: https://git.openjdk.org/jdk/pull/9782 From duke at openjdk.org Fri Aug 5 20:13:17 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Fri, 5 Aug 2022 20:13:17 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call [v2] In-Reply-To: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: > `MacroAssembler::trampoline_call` can skip generation of a trampoline stub if C2 phase output is in the checking emitted code size mode. If it is not C2 compilation, `trampoline_call` always generates a trampoline stub. > > `gen_continuation_enter` as a part of C2 compilation needed to disable the functionality above. Now `trampoline_call` has the `check_emit_size` which allows to disable the functionality completely. Its default value is `true` which means the functionality is enabled. > > There are problems: > - C2 specific code which must be properly guarded if it is not C2 compilation. The code has the risk of undefined behaviour (UB). It is done with `is_c2_compile`. [JDK-8291654](https://bugs.openjdk.org/browse/JDK-8291654) is an example of changes caused UB. > - The default value of `check_emit_size`. The current value `true` allows C1 to access the C2 specific code. Setting the default value to `false` will require to review and to update every existing use of `trampoline_call`. It will complicate uses of `trampoline_call`: each time a decision needs to be done - use or not use the default. > > Summary of changes: > - Have a virtual `emit_trampoline_stub` which is privately overridden in `C2_MacroAssembler`. The overridden version does not emit a stub if C2 phase output is in the checking emitted code size mode. > - `emit_trampoline_stub` returns `bool` instead of `address` because `address` is only used to check the success of a call. > - `check_emit_size` is removed because it is not needed any more. > - `NativeCall::trampoline_jump`: > - Changed to return `void` because the result is not used. It was returning the result of `emit_trampoline_stub`. > - Assert `emit_trampoline_stub`. > > Tested with fastdebug/release builds: > - `gtest`: Passed. > - `tier1`...`tier4`: Passed. Evgeny Astigeevich has updated the pull request incrementally with three additional commits since the last revision: - Restore original NativeCall::trampoline_jump functionality - Substitute entry.target() with target - Remove unneeded assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9782/files - new: https://git.openjdk.org/jdk/pull/9782/files/ab81d0b2..2e5e4aee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9782&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9782&range=00-01 Stats: 10 lines in 3 files changed: 3 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9782.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9782/head:pull/9782 PR: https://git.openjdk.org/jdk/pull/9782 From duke at openjdk.org Fri Aug 5 20:13:19 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Fri, 5 Aug 2022 20:13:19 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call [v2] In-Reply-To: References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: On Fri, 5 Aug 2022 17:40:48 GMT, Vladimir Kozlov wrote: >> Evgeny Astigeevich has updated the pull request incrementally with three additional commits since the last revision: >> >> - Restore original NativeCall::trampoline_jump functionality >> - Substitute entry.target() with target >> - Remove unneeded assert > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1661: > >> 1659: bool C2_MacroAssembler::emit_trampoline_stub(int insts_call_instruction_offset, address target) { >> 1660: if (ciEnv::current()->task() != NULL) { >> 1661: assert(is_c2_compile(ciEnv::current()->task()->comp_level()), "not C2 compilation task"); > > You don't need this assert. `C2_MacroAssembler` is used only in `.ad` files used by C2 only. Done > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 864: > >> 862: // We might need a trampoline if branches are far. >> 863: bool need_trampoline = far_branches(); >> 864: if (!need_trampoline && entry.rspec().type() == relocInfo::runtime_call_type && !CodeCache::contains(entry.target())) { > > In `CodeCache::contains(entry.target())` you can use `target` value. Done ------------- PR: https://git.openjdk.org/jdk/pull/9782 From duke at openjdk.org Fri Aug 5 20:13:21 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Fri, 5 Aug 2022 20:13:21 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call [v2] In-Reply-To: References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: On Fri, 5 Aug 2022 19:22:33 GMT, Evgeny Astigeevich wrote: >> src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp line 541: >> >>> 539: // If we generated no stub, patch this call directly to dest. >>> 540: // This will happen if we don't need far branches or if there >>> 541: // already was a trampoline. >> >> I think this comment should be changed since you changed the code. > > The original code looks strange to me. > If we need a stub but we have failed to create it, we set dest anyway. This will lead to an incorrect instruction. > The behaviour is undefined. We might fail executing the instruction or jump somewhere. I've restored the original functionality. Maybe Andrew(@theRealAph) can explain what should be here. ------------- PR: https://git.openjdk.org/jdk/pull/9782 From kvn at openjdk.org Fri Aug 5 20:26:07 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 5 Aug 2022 20:26:07 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call [v2] In-Reply-To: References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: On Fri, 5 Aug 2022 20:13:17 GMT, Evgeny Astigeevich wrote: >> `MacroAssembler::trampoline_call` can skip generation of a trampoline stub if C2 phase output is in the checking emitted code size mode. If it is not C2 compilation, `trampoline_call` always generates a trampoline stub. >> >> `gen_continuation_enter` as a part of C2 compilation needed to disable the functionality above. Now `trampoline_call` has the `check_emit_size` which allows to disable the functionality completely. Its default value is `true` which means the functionality is enabled. >> >> There are problems: >> - C2 specific code which must be properly guarded if it is not C2 compilation. The code has the risk of undefined behaviour (UB). It is done with `is_c2_compile`. [JDK-8291654](https://bugs.openjdk.org/browse/JDK-8291654) is an example of changes caused UB. >> - The default value of `check_emit_size`. The current value `true` allows C1 to access the C2 specific code. Setting the default value to `false` will require to review and to update every existing use of `trampoline_call`. It will complicate uses of `trampoline_call`: each time a decision needs to be done - use or not use the default. >> >> Summary of changes: >> - Have a virtual `emit_trampoline_stub` which is privately overridden in `C2_MacroAssembler`. The overridden version does not emit a stub if C2 phase output is in the checking emitted code size mode. >> - `emit_trampoline_stub` returns `bool` instead of `address` because `address` is only used to check the success of a call. >> - `check_emit_size` is removed because it is not needed any more. >> - `NativeCall::trampoline_jump`: >> - Changed to return `void` because the result is not used. It was returning the result of `emit_trampoline_stub`. >> - Assert `emit_trampoline_stub`. >> >> Tested with fastdebug/release builds: >> - `gtest`: Passed. >> - `tier1`...`tier4`: Passed. > > Evgeny Astigeevich has updated the pull request incrementally with three additional commits since the last revision: > > - Restore original NativeCall::trampoline_jump functionality > - Substitute entry.target() with target > - Remove unneeded assert Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9782 From duke at openjdk.org Fri Aug 5 20:28:35 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Fri, 5 Aug 2022 20:28:35 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call [v2] In-Reply-To: References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: On Fri, 5 Aug 2022 20:22:17 GMT, Vladimir Kozlov wrote: > Good. @vnkozlov Thank you for reviewing. ------------- PR: https://git.openjdk.org/jdk/pull/9782 From eosterlund at openjdk.org Fri Aug 5 20:37:23 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 5 Aug 2022 20:37:23 GMT Subject: RFR: 8290025: Remove the Sweeper [v6] In-Reply-To: <8o7uSqRhapk7Gtdel7lIfFBVfn7OA-nrMp4MLWncWXA=.2d2747ec-612b-47c9-a733-4f1826b73a17@github.com> References: <8o7uSqRhapk7Gtdel7lIfFBVfn7OA-nrMp4MLWncWXA=.2d2747ec-612b-47c9-a733-4f1826b73a17@github.com> Message-ID: On Fri, 5 Aug 2022 17:14:53 GMT, Igor Veresov wrote: > So in the new world do we always need a GC cycle to flush (as opposed to unload) an method? Yes. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Fri Aug 5 20:37:23 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 5 Aug 2022 20:37:23 GMT Subject: RFR: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 18:17:01 GMT, Boris Ulasevich wrote: > > It still might be that my new algorithm is more aggressive, but the data does not conclude that > > > > I tweaked JMH code to run Warmup iterations for all benchmarks first (a single vm run mode), and than run the final Iterations for the benchmarks (renaissance suite in my case). The idea is to check if a new sweeper algorithm flush the hot methods before the final iteration and get a performance penalty. I played with a benchmark set, combining them into different groups, changing the number of Warmup iterations and VM options. With this approach I do not find evidence that the new algorithm is more aggressive than the previous one. Okay. Thanks for checking. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From iveresov at openjdk.org Fri Aug 5 21:06:07 2022 From: iveresov at openjdk.org (Igor Veresov) Date: Fri, 5 Aug 2022 21:06:07 GMT Subject: RFR: 8290025: Remove the Sweeper [v6] In-Reply-To: References: <8o7uSqRhapk7Gtdel7lIfFBVfn7OA-nrMp4MLWncWXA=.2d2747ec-612b-47c9-a733-4f1826b73a17@github.com> Message-ID: On Fri, 5 Aug 2022 20:34:35 GMT, Erik ?sterlund wrote: > > So in the new world do we always need a GC cycle to flush (as opposed to unload) an method? > > Yes. Hm.. That may turn out to be a problem. But with loom it's probably the only way... ------------- PR: https://git.openjdk.org/jdk/pull/9741 From iveresov at openjdk.org Fri Aug 5 21:21:12 2022 From: iveresov at openjdk.org (Igor Veresov) Date: Fri, 5 Aug 2022 21:21:12 GMT Subject: RFR: 8290025: Remove the Sweeper [v6] In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 10:10:28 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund 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 8290025_remove_sweeper > - Removed more stale things > - Remove incorrect comment > - Feedback v2 > - Feedback v1 > - 8290025: Remove the Sweeper Marked as reviewed by iveresov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Fri Aug 5 21:58:06 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 5 Aug 2022 21:58:06 GMT Subject: RFR: 8290025: Remove the Sweeper [v6] In-Reply-To: References: <8o7uSqRhapk7Gtdel7lIfFBVfn7OA-nrMp4MLWncWXA=.2d2747ec-612b-47c9-a733-4f1826b73a17@github.com> Message-ID: On Fri, 5 Aug 2022 21:02:51 GMT, Igor Veresov wrote: > > > So in the new world do we always need a GC cycle to flush (as opposed to unload) an method? > > > > > > Yes. > > > > Hm.. That may turn out to be a problem. But with loom it's probably the only way... Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From kvn at openjdk.org Fri Aug 5 22:02:11 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 5 Aug 2022 22:02:11 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 16:36:23 GMT, Smita Kamath wrote: > 8289552: Make intrinsic conversions between bit representations of half precision values and floats Please add JMH microbenchmark and show results. ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9781 From darcy at openjdk.org Fri Aug 5 22:19:03 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 5 Aug 2022 22:19:03 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 16:36:23 GMT, Smita Kamath wrote: > 8289552: Make intrinsic conversions between bit representations of half precision values and floats src/hotspot/share/runtime/sharedRuntime.cpp line 450: > 448: JRT_END > 449: > 450: JRT_LEAF(jshort, SharedRuntime::f2hf(jfloat x)) Is it necessary/desirable to have a transliteration of the Java implementation here rather than just using the Java library implementation? ------------- PR: https://git.openjdk.org/jdk/pull/9781 From svkamath at openjdk.org Fri Aug 5 22:52:05 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Fri, 5 Aug 2022 22:52:05 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 21:58:40 GMT, Vladimir Kozlov wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Please add JMH microbenchmark and show results. @vnkozlov Thank you for your comment. I will add a jmh test case. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From svkamath at openjdk.org Fri Aug 5 22:54:14 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Fri, 5 Aug 2022 22:54:14 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 22:15:37 GMT, Joe Darcy wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > src/hotspot/share/runtime/sharedRuntime.cpp line 450: > >> 448: JRT_END >> 449: >> 450: JRT_LEAF(jshort, SharedRuntime::f2hf(jfloat x)) > > Is it necessary/desirable to have a transliteration of the Java implementation here rather than just using the Java library implementation? @jddarcy Thanks for your comment. I am not sure if there is a way of using Java library implementation here. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From coleenp at openjdk.org Fri Aug 5 23:04:06 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 5 Aug 2022 23:04:06 GMT Subject: RFR: 8291459: JVM crash with GenerateOopMap::error_work(char const*, __va_list_tag*) [v3] In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 13:44:05 GMT, Harold Seigel wrote: >> The JVM fails when generating oop maps for method getAlphanumericCode(int) in bug_file/com/google/zxing/qrcode/encoder/Encoder.javap because the last bytecode in the method is an unreachable conditional branch at byecode index 11131: >> >> 11124: ireturn >> 11125: iinc 41, 1 >> 11128: iload 41 >> 11130: iconst_2 >> 11131: if_icmple 291 >> >> The class file (Encoder.class) containing getAlphanumericCode(int) has a class file version of 49. So it is verified by the old verifier, which allows methods to end in a conditional branch provided that the conditional branch is unreachable during method execution. >> >> This fix changes GenerateOopMap::jump_targets_do() to handle such methods. >> >> The fix was tested by running the user's failing program, the new regression test, Mach5 tiers 1-2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linu x64, and the JC Lang,VM, and API tests locally on Linux x64. >> >> Please review. >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > remove packages from test classes This looks good and like a safe fix. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/9745 From darcy at openjdk.org Sat Aug 6 00:02:06 2022 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 6 Aug 2022 00:02:06 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 22:52:10 GMT, Smita Kamath wrote: >> src/hotspot/share/runtime/sharedRuntime.cpp line 450: >> >>> 448: JRT_END >>> 449: >>> 450: JRT_LEAF(jshort, SharedRuntime::f2hf(jfloat x)) >> >> Is it necessary/desirable to have a transliteration of the Java implementation here rather than just using the Java library implementation? > > @jddarcy Thanks for your comment. I am not sure if there is a way of using Java library implementation here. I was under the impression that if a platform didn't have special support for the functionality in question it could not have the intrinsic and just use the Java library implementation? ------------- PR: https://git.openjdk.org/jdk/pull/9781 From iklam at openjdk.org Sat Aug 6 00:44:04 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 6 Aug 2022 00:44:04 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp Message-ID: To improve modularity and build time, move the declaration of the following accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp: + java_lang_Thread_FieldHolder + java_lang_Thread_Constants + java_lang_ThreadGroup + java_lang_VirtualThread Also move javaThreadStatus.hpp from share/classfile to share/runtime, where it belongs. ------------- Commit messages: - 8292006: Move thread accessor classes to threadJavaClasses.hpp Changes: https://git.openjdk.org/jdk/pull/9788/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9788&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292006 Stats: 1912 lines in 33 files changed: 1016 ins; 891 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9788.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9788/head:pull/9788 PR: https://git.openjdk.org/jdk/pull/9788 From coleenp at openjdk.org Sat Aug 6 00:47:27 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 6 Aug 2022 00:47:27 GMT Subject: RFR: 8290025: Remove the Sweeper [v6] In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 10:10:28 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund 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 8290025_remove_sweeper > - Removed more stale things > - Remove incorrect comment > - Feedback v2 > - Feedback v1 > - 8290025: Remove the Sweeper Wow, this is great. src/hotspot/share/code/codeCache.cpp line 984: > 982: nm->flush(); > 983: if (next == nm) { > 984: // Self looped means end of list Why not nullptr for the end of the list? src/hotspot/share/code/codeCache.cpp line 1312: > 1310: CompiledMethod* cm = old_compiled_method_table->at(i); > 1311: // Only walk !is_unloading nmethods, the other ones will get removed by the GC. > 1312: if (!cm->is_unloading()) { I thought we were going to walk the unloading methods? Or should that be another bug fix? It's unlikely to ever find a reproducer so I wouldn't mind if it was fixed with this giant patch. src/hotspot/share/code/nmethod.cpp line 761: > 759: _comp_level = comp_level; > 760: _orig_pc_offset = orig_pc_offset; > 761: _gc_epoch = CodeCache::gc_epoch(); Good to move this. src/hotspot/share/code/nmethod.cpp line 1316: > 1314: > 1315: // Change state > 1316: bool success = try_transition(not_entrant); I suppose in a further RFE, you could rename try_transition or do the transition inline. Does it still CAS? src/hotspot/share/code/nmethod.cpp line 1712: > 1710: mark_as_seen_on_stack(); > 1711: } > 1712: Thank you! It's nice to see this code which still may have bugs removed. src/hotspot/share/code/nmethod.hpp line 268: > 266: > 267: // Protected by CompiledMethod_lock > 268: volatile signed char _state; // {not_installed, in_use, not_entrant} There's a fourth state: not_used which you might as well add to the comment ? src/hotspot/share/oops/constantPool.cpp line 2222: > 2220: } > 2221: > 2222: // If the condition below is true, it means that the nmethod was found to I think this comment should say Method and not nmethod. I think this was a cut and paste error. I assume that the is_maybe_on_stack is generalizing "stack" meaning on the execution OR continuation stack ? ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/9741 From dlong at openjdk.org Sat Aug 6 04:16:13 2022 From: dlong at openjdk.org (Dean Long) Date: Sat, 6 Aug 2022 04:16:13 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v5] In-Reply-To: References: <5JfLyDDTi0H7WRva8W0WV7hI3xKvxVo7mPyaWzpx1pw=.a682010e-356f-4972-a343-a2058fa2b2ef@github.com> Message-ID: On Fri, 5 Aug 2022 08:15:44 GMT, Erik ?sterlund wrote: >> My concern was that we could be removing the dependencies from nmethods that are still using them. But if that was the case, the old code would have the same problem. > > The compiler dependencies are protecting against loading of a class that is a subtype of X. If X is unloaded, then we can be pretty sure nobody is going to load a subclass of X. Isn't there something we can assert about the state of these nmethods? Maybe unlinked and !in_use? ------------- PR: https://git.openjdk.org/jdk/pull/9713 From fyang at openjdk.org Sat Aug 6 07:27:04 2022 From: fyang at openjdk.org (Fei Yang) Date: Sat, 6 Aug 2022 07:27:04 GMT Subject: RFR: 8291893: riscv: remove fence.i used in user space In-Reply-To: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> References: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> Message-ID: On Fri, 5 Aug 2022 09:37:54 GMT, Yadong Wang wrote: > The usage of fence.i is in-efficient or redundant in the current implementation of riscv port now. The riscv port has already followed the [RISC-V platform specification](https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc): the write hart use the __builtin__clear_cache or the syscall riscv_flush_icache directly after modifying code in riscv port, to execute fence.i on local hart and other harts by IPI. That's because fence.i only synchronizes the local hart, and the OS can reschedule the user hart to a different physical hart after the fence.i. > > "To order older stores before younger instruction fetches, user-level programs must use system supplied > library calls (e.g. GNU libc's __riscv_flush_icache, which invokes the Linux kernel's > corresponding vDSO routine), rather than executing the fence.i instruction directly." > > What now seems unnecessary is that we also put fence.i in front of code that will be modifed concurrently, just like Aarch64 port. Because the icache flush syscall already provides the explicit icache synchronization between all harts, so that we can remove fence.i used in the read hart. > Details of the discussion can be found in https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000571.html. > > In contrast, the isb in aarch64 is not broadcast by the writing PE, so any other PE must perform its own isb synchronization after it knows that the instruction update is visible. > > Tier1 of hotspot and jdk passed on unmatched. The changes looks reasonable to me. But looks like the data fence suggested before __builtin___clear_cache in icache_flush is missing? As discussed on the list, we need to explicitly add this data fence to be safe since it is not specified by the riscv_flush_icache syscall issued from __builtin___clear_cache. ------------- PR: https://git.openjdk.org/jdk/pull/9770 From duke at openjdk.org Sat Aug 6 09:05:12 2022 From: duke at openjdk.org (Patrick Pfeifer) Date: Sat, 6 Aug 2022 09:05:12 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> References: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> Message-ID: On Mon, 18 Jul 2022 15:22:01 GMT, Jonathan Gibbons wrote: >> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. >> >> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: >> >> The Java manpage was missing updates from: >> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page. >> >> The Java manpage has slight formatting differences from: >> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux >> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS >> >> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) >> >> >> The keytool manpage was missing updates from: >> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page. >> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA >> >> The jar manpage was missing updates from: >> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) >> >> The jarsigner manpage was missing updates from: >> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page. >> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA >> >> The javadoc manpage was missing updates from: >> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option >> >> The jmod manpage was missing updates from: >> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) >> >> The jpackage manpage was missing updates from: >> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature >> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19 >> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code >> >> The jshell manpage was missing updates from: >> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page. > > src/java.base/share/man/keytool.1 line 456: > >> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the >> 455: keystore. >> 456: This option is used to sign the certificate with the signer?s private > > Not a problem with this PR as such, but we still have a `?` character in the output. Hello @jonathan-gibbons Excuse my hijacking / piggy-backing on this conversation! When you say > Not a problem with this PR as such, but we still have a `?` character in the output. This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo? Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build. I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web? ------------- PR: https://git.openjdk.org/jdk19/pull/145 From jwaters at openjdk.org Sat Aug 6 10:18:08 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 6 Aug 2022 10:18:08 GMT Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v3] In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 17:42:45 GMT, Julian Waters wrote: >> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr. > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Missing spacing between errors Not entirely sure if that's the intended use of JLI_ReportErrorMessageSys, but since Windows doesn't actually use it normally, the fixing change to it should have minimal impact, if at all ------------- PR: https://git.openjdk.org/jdk/pull/9749 From stuefe at openjdk.org Sat Aug 6 10:57:59 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 6 Aug 2022 10:57:59 GMT Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v3] In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 17:42:45 GMT, Julian Waters wrote: >> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr. > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Missing spacing between errors Hi Julian, I don't get it. AFAICS the existing version displays the failure reason for win32 API just fine, appending it to the message. Where is the bug? I see that the message was omitted for CRT errors, so that is okay to fix, but that could have been fixed with a simple freeit=1 in the CRT error path (although my taste would be to just append errtxt if errtxt!=NULL, which is less circumvent). I also do not understand the changes to the call sites, where you add "%s". What is the point? If you want to separate error message and detail error message with " - ", you can just do an additional conditional strcat in the error message function. Cheers, Thomas src/java.base/share/native/libjli/emessages.h line 111: > 109: #define DLL_ERROR2 "Error: failed %s, because %s" > 110: #define DLL_ERROR3 "Error: could not find executable %s" > 111: #define DLL_ERROR4 "Error: Failed to load %s" Have you looked into all usages of this macro, also non-windows/shared code? Please make sure the replacement text makes sense in all those cases. ------------- PR: https://git.openjdk.org/jdk/pull/9749 From jwaters at openjdk.org Sat Aug 6 11:21:03 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 6 Aug 2022 11:21:03 GMT Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v3] In-Reply-To: References: Message-ID: <-yq150PwHL8GFLfByzLTrTH7QfTgAxhMm95KKKBik9A=.2a77ad93-9e4f-4701-8913-a8c3baf63ff6@github.com> On Sat, 6 Aug 2022 10:36:05 GMT, Thomas Stuefe wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing spacing between errors > > src/java.base/share/native/libjli/emessages.h line 111: > >> 109: #define DLL_ERROR2 "Error: failed %s, because %s" >> 110: #define DLL_ERROR3 "Error: could not find executable %s" >> 111: #define DLL_ERROR4 "Error: Failed to load %s" > > Have you looked into all usages of this macro, also non-windows/shared code? Please make sure the replacement text makes sense in all those cases. The only non Windows code that uses the `DLL_ERROR4` macro is Unix's java_md_common.c, where it reports the same `JVM_FindClassFromBootLoader` issue that Windows also does, and the shared args.c when a file cannot be found by path: static JLI_List expandArgFile(const char *arg) { JLI_List rv; struct stat st; FILE *fptr = fopen(arg, "r"); /* arg file cannot be opened */ if (fptr == NULL || fstat(fileno(fptr), &st) != 0) { JLI_ReportMessage(CFG_ERROR6, arg); exit(1); } else { if (st.st_size > MAX_ARGF_SIZE) { JLI_ReportMessage(CFG_ERROR10, MAX_ARGF_SIZE); exit(1); } } rv = readArgFile(fptr); /* error occurred reading the file */ if (rv == NULL) { JLI_ReportMessage(DLL_ERROR4, arg); exit(1); } fclose(fptr); return rv; } In any case, the only thing that would change would be "Error: loading:" to "Error: Failed to load" as the prefix of the message, which semantically is the same whatever the context may be, just a small change I thought that would look better whenever the macro is used ------------- PR: https://git.openjdk.org/jdk/pull/9749 From stuefe at openjdk.org Sat Aug 6 11:40:06 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 6 Aug 2022 11:40:06 GMT Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v3] In-Reply-To: <-yq150PwHL8GFLfByzLTrTH7QfTgAxhMm95KKKBik9A=.2a77ad93-9e4f-4701-8913-a8c3baf63ff6@github.com> References: <-yq150PwHL8GFLfByzLTrTH7QfTgAxhMm95KKKBik9A=.2a77ad93-9e4f-4701-8913-a8c3baf63ff6@github.com> Message-ID: On Sat, 6 Aug 2022 11:14:55 GMT, Julian Waters wrote: >> src/java.base/share/native/libjli/emessages.h line 111: >> >>> 109: #define DLL_ERROR2 "Error: failed %s, because %s" >>> 110: #define DLL_ERROR3 "Error: could not find executable %s" >>> 111: #define DLL_ERROR4 "Error: Failed to load %s" >> >> Have you looked into all usages of this macro, also non-windows/shared code? Please make sure the replacement text makes sense in all those cases. > > The only non Windows code that uses the `DLL_ERROR4` macro is Unix's java_md_common.c, where it reports the same `JVM_FindClassFromBootLoader` issue that Windows also does, and the shared args.c when a file cannot be found by path: > > static JLI_List expandArgFile(const char *arg) { > JLI_List rv; > struct stat st; > FILE *fptr = fopen(arg, "r"); > > /* arg file cannot be opened */ > if (fptr == NULL || fstat(fileno(fptr), &st) != 0) { > JLI_ReportMessage(CFG_ERROR6, arg); > exit(1); > } else { > if (st.st_size > MAX_ARGF_SIZE) { > JLI_ReportMessage(CFG_ERROR10, MAX_ARGF_SIZE); > exit(1); > } > } > > rv = readArgFile(fptr); > > /* error occurred reading the file */ > if (rv == NULL) { > JLI_ReportMessage(DLL_ERROR4, arg); > exit(1); > } > fclose(fptr); > > return rv; > } > > > In any case, the only thing that would change would be "Error: loading:" to "Error: Failed to load" as the prefix of the message, which semantically is the same whatever the context may be, just a small change I thought that would look better whenever the macro is used You also have one use where the VM does a GetProcAddress on windows. "Failed to load" feels wrong for a failed dlsym. But "Error loading" is not much better either, I admit. In general, the smaller and focused you keep changes, the easier they are to review and the better they are down-portable if that should be needed. I usually try to do aesthetic changes in separate RFEs. In this change, if you want to fix the display of additional diagnostic info, I'd just do that. ------------- PR: https://git.openjdk.org/jdk/pull/9749 From jwaters at openjdk.org Sat Aug 6 12:23:07 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 6 Aug 2022 12:23:07 GMT Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v3] In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 10:54:56 GMT, Thomas Stuefe wrote: > Hi Julian, > > I don't get it. > > AFAICS the existing version displays the failure reason for win32 API just fine, appending it to the message. Where is the bug? I see that the message was omitted for CRT errors, so that is okay to fix, but that could have been fixed with a simple freeit=1 in the CRT error path (although my taste would be to just append errtxt if errtxt!=NULL, which is less circumvent). > > I also do not understand the changes to the call sites, where you add "%s". What is the point? If you want to separate error message and detail error message with " - ", you can just do an additional conditional strcat in the error message function. > > Cheers, Thomas Hi Thomas, sorry for the delay, Yes, the bug was the CRT errors being omitted, the issue with setting freeit for CRT errors too is that it, from what I can see, is only supposed to be used by the branch for Win32 errors, and is used for calling LocalFree (required for FormatMessage) later on. Setting this for CRT errors would mean LocalFree is passed something that LocalAlloc did not allocate, which would likely result in bad things happening. I didn't feel like changing too much of the existing logic just to fix a small issue and decided to leave the calculation and concatenation of the message to other JLI functions, but that may have been a misjudgement on my part. JLI_ReportErrorMessageSys is documented to deliberately leave the formatting of spacing up to the caller - Which is why no changes were made to it to accomodate that quirk. Admittedly a strcat could've been used in the caller rather than an additional format specifer though, like you mentioned best regards, Julian ------------- PR: https://git.openjdk.org/jdk/pull/9749 From jwaters at openjdk.org Sat Aug 6 12:23:08 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 6 Aug 2022 12:23:08 GMT Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v3] In-Reply-To: References: <-yq150PwHL8GFLfByzLTrTH7QfTgAxhMm95KKKBik9A=.2a77ad93-9e4f-4701-8913-a8c3baf63ff6@github.com> Message-ID: <8r07t1mVOVOCYQCHcDubl1_ZxPyJvOsEj0_V6EIwUAA=.4d2573fe-c025-4a9a-8a76-ac6b1b7241a1@github.com> On Sat, 6 Aug 2022 11:36:44 GMT, Thomas Stuefe wrote: >> The only non Windows code that uses the `DLL_ERROR4` macro is Unix's java_md_common.c, where it reports the same `JVM_FindClassFromBootLoader` issue that Windows also does, and the shared args.c when a file cannot be found by path: >> >> static JLI_List expandArgFile(const char *arg) { >> JLI_List rv; >> struct stat st; >> FILE *fptr = fopen(arg, "r"); >> >> /* arg file cannot be opened */ >> if (fptr == NULL || fstat(fileno(fptr), &st) != 0) { >> JLI_ReportMessage(CFG_ERROR6, arg); >> exit(1); >> } else { >> if (st.st_size > MAX_ARGF_SIZE) { >> JLI_ReportMessage(CFG_ERROR10, MAX_ARGF_SIZE); >> exit(1); >> } >> } >> >> rv = readArgFile(fptr); >> >> /* error occurred reading the file */ >> if (rv == NULL) { >> JLI_ReportMessage(DLL_ERROR4, arg); >> exit(1); >> } >> fclose(fptr); >> >> return rv; >> } >> >> >> In any case, the only thing that would change would be "Error: loading:" to "Error: Failed to load" as the prefix of the message, which semantically is the same whatever the context may be, just a small change I thought that would look better whenever the macro is used > > You also have one use where the VM does a GetProcAddress on windows. "Failed to load" feels wrong for a failed dlsym. But "Error loading" is not much better either, I admit. > > In general, the smaller and focused you keep changes, the easier they are to review and the better they are down-portable if that should be needed. I usually try to do aesthetic changes in separate RFEs. In this change, if you want to fix the display of additional diagnostic info, I'd just do that. Agreed, will split this part into another RFE (initially didn't do this because such a change felt too trivial for an entire entry in the JBS), but I do feel like waiting for more opinions on what the prefix should be changed to before doing that ------------- PR: https://git.openjdk.org/jdk/pull/9749 From stuefe at openjdk.org Sat Aug 6 13:08:56 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 6 Aug 2022 13:08:56 GMT Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v3] In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 17:42:45 GMT, Julian Waters wrote: >> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr. > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Missing spacing between errors Hi Julian, > > Hi Julian, > > I don't get it. > > AFAICS the existing version displays the failure reason for win32 API just fine, appending it to the message. Where is the bug? I see that the message was omitted for CRT errors, so that is okay to fix, but that could have been fixed with a simple freeit=1 in the CRT error path (although my taste would be to just append errtxt if errtxt!=NULL, which is less circumvent). > > I also do not understand the changes to the call sites, where you add "%s". What is the point? If you want to separate error message and detail error message with " - ", you can just do an additional conditional strcat in the error message function. > > Cheers, Thomas > > Hi Thomas, sorry for the delay, > why, there was no delay :-) > Yes, the bug was the CRT errors being omitted, the issue with setting freeit for CRT errors too is that it, from what I can see, is only supposed to be used by the branch for Win32 errors, and is used for calling LocalFree (required for FormatMessage) later on. Setting this for CRT errors would mean LocalFree is passed something that LocalAlloc did not allocate, which would likely result in bad things happening. Oh right. I see. Not your change, but I am not a big fan of this pattern (mixing CRT and win32 error handling). This is broken since it assumes that win32 error code and errno are mutually exclusive, or somehow related, which they are not. A lingering GetLastError() from some earlier win32 API call could be misreported as error detail for a follow-up CRT error. The correct way to do this would be to have two functions, one for failing win32 APIs, one for failing CRT functions. And let the caller decide what to call. > I didn't feel like changing too much of the existing logic just to fix a small issue and decided to leave the calculation and concatenation of the message to other JLI functions, but that may have been a misjudgement on my part. If you can make the fix for the CRT extra info small, I'd go for it. > > JLI_ReportErrorMessageSys is documented to deliberately leave the formatting of spacing up to the caller - Which is why no changes were made to it to accomodate that quirk. Admittedly a strcat could've been used in the caller rather than an additional format specifer though, like you mentioned I think it would be reasonable to expect that the additional info printed by that function gets visually separated somehow from the error text the caller hands in. Note, btw, if you change output like this, make sure to check all test sources for tests that may grep the output. Not sure how likely this is here. Just something to keep in mind. This is nothing an IDE will tell you, unfortunately. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/9749 From stuefe at openjdk.org Sat Aug 6 13:21:57 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 6 Aug 2022 13:21:57 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam wrote: > To improve modularity and build time, move the declaration of the following accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp: > > + java_lang_Thread_FieldHolder > + java_lang_Thread_Constants > + java_lang_ThreadGroup > + java_lang_VirtualThread > > Also move javaThreadStatus.hpp from share/classfile to share/runtime, where it belongs. Hi Ioi, looks good. Small nits inline. I did not check that the moved code is identical, because I assume you just moved it around unchanged. Cheers, Thomas src/hotspot/share/runtime/threadJavaClasses.cpp line 36: > 34: #include "runtime/threadJavaClasses.hpp" > 35: #include "runtime/threadSMR.hpp" > 36: #include "runtime/vframe.inline.hpp" needs debug.hpp and macros.hpp, at least, to be self-contained. Probably globalDefinitions.hpp too. src/hotspot/share/runtime/threadJavaClasses.hpp line 31: > 29: #include "memory/allStatic.hpp" > 30: #include "oops/oopsHierarchy.hpp" > 31: #include "runtime/os.hpp" Where do you need os.hpp? src/hotspot/share/runtime/threadJavaClasses.inline.hpp line 32: > 30: #include "oops/instanceKlass.inline.hpp" > 31: #include "oops/oop.inline.hpp" > 32: #include "oops/oopsHierarchy.hpp" I believe that for INCLUDE_JFR you need macros.hpp, or? Highly likely it's already there, or you'd get linker errors. But it should be explicit. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/9788 From duke at openjdk.org Sat Aug 6 13:54:20 2022 From: duke at openjdk.org (Patrick Pfeifer) Date: Sat, 6 Aug 2022 13:54:20 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> Message-ID: <_53Ro95x3TDbVcRUoOr4L0HiWCyepU8CgcyPCwLwKLA=.6ce49e6c-9b4b-4c8e-b0b8-7ec76b0f3d85@github.com> On Sat, 6 Aug 2022 09:01:39 GMT, Patrick Pfeifer wrote: >> src/java.base/share/man/keytool.1 line 456: >> >>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the >>> 455: keystore. >>> 456: This option is used to sign the certificate with the signer?s private >> >> Not a problem with this PR as such, but we still have a `?` character in the output. > > Hello @jonathan-gibbons > > Excuse my hijacking / piggy-backing on this conversation! > > When you say > >> Not a problem with this PR as such, but we still have a `?` character in the output. > > This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo? > > Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build. > > I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web? It did not take much effort to answer the last of the above question myself. > Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web? Obviously "yes". HTML renderings can be found by following the, e.g. "[Java Development Kit Version 18 Tool Specifications](https://docs.oracle.com/en/java/javase/18/docs/specs/man/index.html)" Link on the "Specifications Overview" page at, e.g. "https://docs.oracle.com/en/java/javase/18/docs/specs/". Still hunting for the sources. ------------- PR: https://git.openjdk.org/jdk19/pull/145 From jwaters at openjdk.org Sat Aug 6 16:45:06 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 6 Aug 2022 16:45:06 GMT Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v4] In-Reply-To: References: Message-ID: > Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Back out change to DLL_ERROR4 for separate RFE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9749/files - new: https://git.openjdk.org/jdk/pull/9749/files/3bd53488..990ee4fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9749.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9749/head:pull/9749 PR: https://git.openjdk.org/jdk/pull/9749 From jwaters at openjdk.org Sun Aug 7 06:14:48 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 7 Aug 2022 06:14:48 GMT Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v4] In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 16:45:06 GMT, Julian Waters wrote: >> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr. > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Back out change to DLL_ERROR4 for separate RFE Nothing I could find in the tests that suggest they use this message as input, and none of them have failed with this patch, so I guess that's a good thing? :P I am slightly concerned with going the route of 2 different calls for WIN32 and the C runtime, since `JLI_ReportErrorMessageSys` is a shared function, only the implementations differ from platform to platform. I can't think of any solution off the top of my head to implement such a change without drastically changing either the Unix variant as well, or the declaration's signature in the shared header unfortunately. I was initially hesitant to change the formatting of spacing between the caller's message and system error, since the original intention for leaving it up to the caller may have been to allow for better flexibility. Also a concern was any behaviour differences that might result with the Unix variant, but it seems like the 2 format their messages entirely differently - While Windows appends the system error to the message without any formatting, Unix prints the system error on an entirely separate line above the message the caller passed it: JNIEXPORT void JNICALL JLI_ReportErrorMessageSys(const char* fmt, ...) { va_list vl; char *emsg; /* * TODO: its safer to use strerror_r but is not available on * Solaris 8. Until then.... */ emsg = strerror(errno); if (emsg != NULL) { fprintf(stderr, "%s\n", emsg); } va_start(vl, fmt); vfprintf(stderr, fmt, vl); fprintf(stderr, "\n"); va_end(vl); } > If you can make the fix for the CRT extra info small, I'd go for it. I don't quite get what you mean by that, should I revert the changes made to the freeit checks? ------------- PR: https://git.openjdk.org/jdk/pull/9749 From stuefe at openjdk.org Sun Aug 7 07:50:49 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 7 Aug 2022 07:50:49 GMT Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v4] In-Reply-To: References: Message-ID: On Sun, 7 Aug 2022 06:10:21 GMT, Julian Waters wrote: > I don't quite get what you mean by that, should I revert the changes made to the freeit checks? I looked over this function and found a number of issues with it. I created https://bugs.openjdk.org/browse/JDK-8292016 to track those (if you feel like it, feel free to take it over). I think now that this PR fixes an isolated problem, but it would be better and less review work to rework this function as https://bugs.openjdk.org/browse/JDK-8292016 suggests. I also believe that your bug description in the JBS does not correctly describe the Bug. See my comment in JBS. If you open bugs like this, it is always helpful to be precise, and possibly append failing output (e.g. in this case the output of DLL load errors). ------------- PR: https://git.openjdk.org/jdk/pull/9749 From alanb at openjdk.org Sun Aug 7 08:00:42 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 7 Aug 2022 08:00:42 GMT Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v4] In-Reply-To: References: Message-ID: On Sun, 7 Aug 2022 07:47:04 GMT, Thomas Stuefe wrote: > If you open bugs like this, it is always helpful to be precise, and possibly append failing output (e.g. in this case the output of DLL load errors). I agree, I think it would be useful to provide a summary where the launcher fails and the before/after output so that it's clear what we are looking at. ------------- PR: https://git.openjdk.org/jdk/pull/9749 From stuefe at openjdk.org Sun Aug 7 08:00:43 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 7 Aug 2022 08:00:43 GMT Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v4] In-Reply-To: References: Message-ID: <0uuBnaZ4vxnwvwqPZzTniup_5ZxVSs_iq47NGmUzLFg=.09f9ee79-d50a-40ab-87aa-37a1a36e7699@github.com> On Sun, 7 Aug 2022 06:10:21 GMT, Julian Waters wrote: > Nothing I could find in the tests that suggest they use this message as input, and none of them have failed with this patch, so I guess that's a good thing? :P Oh, that is fine :) Thanks for looking. I just mentioned it since you are new-ish. The tests that run as part of GHAs are only a tiny subset of all tests though, therefore there can be tests that fail and you would not notice. About the rest, starting to pull a thread somewhere and then noticing that the thread gets longer and longer is a normal thing. Then its up to you to decide whether fixing the isolated issue is worth it or whether more code needs to be reworked. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/9749 From jwaters at openjdk.org Sun Aug 7 08:39:42 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 7 Aug 2022 08:39:42 GMT Subject: RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v4] In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 16:45:06 GMT, Julian Waters wrote: >> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. This also fixes a small bug in the Windows implementation of JLI_ErrorMessageSys where C runtime errors are never written to stderr. > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Back out change to DLL_ERROR4 for separate RFE Yeah, does seem like this PR is going to have to wait until [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) is resolved ------------- PR: https://git.openjdk.org/jdk/pull/9749 From rsunderbabu at openjdk.org Sun Aug 7 12:50:42 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Sun, 7 Aug 2022 12:50:42 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v2] In-Reply-To: References: Message-ID: > Tested with all GC options Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9658/files - new: https://git.openjdk.org/jdk/pull/9658/files/8a70905b..3d0e3948 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9658&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9658&range=00-01 Stats: 30 lines in 9 files changed: 20 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/9658.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9658/head:pull/9658 PR: https://git.openjdk.org/jdk/pull/9658 From rsunderbabu at openjdk.org Sun Aug 7 14:30:45 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Sun, 7 Aug 2022 14:30:45 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v2] In-Reply-To: References: Message-ID: On Sun, 7 Aug 2022 12:50:42 GMT, Ramkumar Sunderbabu wrote: >> Tested with all GC options > > Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: > > 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" Tested for all GC types - G1GC, SerialGC, ParallelGC, ZGC. ------------- PR: https://git.openjdk.org/jdk/pull/9658 From dholmes at openjdk.org Sun Aug 7 22:13:03 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 7 Aug 2022 22:13:03 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam wrote: > To improve modularity and build time, move the declaration of the following accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp: > > + java_lang_Thread_FieldHolder > + java_lang_Thread_Constants > + java_lang_ThreadGroup > + java_lang_VirtualThread > > Also move javaThreadStatus.hpp from share/classfile to share/runtime, where it belongs. javaClasses is not meant to be modular, and moving just a handful of items does not make it modular. I really like having all these Java accessors in one place. ------------- PR: https://git.openjdk.org/jdk/pull/9788 From dholmes at openjdk.org Sun Aug 7 22:16:43 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 7 Aug 2022 22:16:43 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 13:09:01 GMT, Thomas Stuefe wrote: >> To improve modularity and build time, move the declaration of the following accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp: >> >> + java_lang_Thread_FieldHolder >> + java_lang_Thread_Constants >> + java_lang_ThreadGroup >> + java_lang_VirtualThread >> >> Also move javaThreadStatus.hpp from share/classfile to share/runtime, where it belongs. > > src/hotspot/share/runtime/threadJavaClasses.inline.hpp line 32: > >> 30: #include "oops/instanceKlass.inline.hpp" >> 31: #include "oops/oop.inline.hpp" >> 32: #include "oops/oopsHierarchy.hpp" > > I believe that for INCLUDE_JFR you need macros.hpp, or? Highly likely it's already there, or you'd get linker errors. But it should be explicit. It is included in the .hpp file as it should be. ------------- PR: https://git.openjdk.org/jdk/pull/9788 From david.holmes at oracle.com Sun Aug 7 23:59:08 2022 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Aug 2022 09:59:08 +1000 Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> Message-ID: <161d24ca-ff52-b2fe-0874-461e98900e28@oracle.com> Hi Patrick, On 6/08/2022 7:05 pm, Patrick Pfeifer wrote: > On Mon, 18 Jul 2022 15:22:01 GMT, Jonathan Gibbons wrote: > >>> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. >> >> Not a problem with this PR as such, but we still have a `?` character in the output. > > Hello @jonathan-gibbons > > Excuse my hijacking / piggy-backing on this conversation! > > When you say > >> Not a problem with this PR as such, but we still have a `?` character in the output. > > This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo? The sources to the manpages are not currently open sourced and so are held in Oracle's internal repository. Making them open-sourced has been a goal for some time now but has to overcome legal obstacles, but we are hopeful it will be "soon". > Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build. > > I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web? As you found, Oracle does provide these in html format. Cheers, David > ------------- > > PR: https://git.openjdk.org/jdk19/pull/145 From dholmes at openjdk.org Mon Aug 8 01:30:03 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Aug 2022 01:30:03 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam wrote: > To improve modularity and build time, move the declaration of the following accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp: > > + java_lang_Thread_FieldHolder > + java_lang_Thread_Constants > + java_lang_ThreadGroup > + java_lang_VirtualThread > > Also move javaThreadStatus.hpp from share/classfile to share/runtime, where it belongs. My issue with these kinds of changes in general is that they: - undermine institutional memory - make it harder to do backports due to the shuffling - make it harder to track changes due to the shuffling So the benefit to me has to be more than just a small decrease in some build times which most people are never going to notice anyway. Sorry. Just my 2c. ------------- PR: https://git.openjdk.org/jdk/pull/9788 From iklam at openjdk.org Mon Aug 8 02:17:41 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 8 Aug 2022 02:17:41 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp In-Reply-To: References: Message-ID: <8uh4O1V5TnmKsKxB0blcohCIcM26deY35AKvEG11l_I=.1213fbe8-9793-46ee-9f6e-c2c82b55cfaf@github.com> On Mon, 8 Aug 2022 01:26:11 GMT, David Holmes wrote: > My issue with these kinds of changes in general is that they: > > * undermine institutional memory > * make it harder to do backports due to the shuffling > * make it harder to track changes due to the shuffling > > So the benefit to me has to be more than just a small decrease in some build times which most people are never going to notice anyway. Sorry. Just my 2c. While I understand the concerns, the above reason can be used against any sort of refactoring of the source code. We have a few decades of development, resulting slow but steady source code rot. We need to refactor the code when it makes sense to keep the repo healthy. Yes, the above are valid concerns, but we have been successful in dealing with them in past refactoring exercises. Build time is important for HotSpot developers. I figure that the header file refactoring that happened in the last year or so (by myself and others) have resulted in 20% or so reduction in build time. So of that was taken back, though, due to new features such as Loom. I tried to limit the amount of code to be moved. However, when a file like javaClasses.hpp grows to over 2000 lines or mostly unrelated declarations, it's a sign that it needs to be broken up (which I started doing since JDK-8288623). ------------- PR: https://git.openjdk.org/jdk/pull/9788 From yadongwang at openjdk.org Mon Aug 8 02:19:42 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Mon, 8 Aug 2022 02:19:42 GMT Subject: RFR: 8291893: riscv: remove fence.i used in user space [v2] In-Reply-To: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> References: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> Message-ID: > The usage of fence.i is in-efficient or redundant in the current implementation of riscv port now. The riscv port has already followed the [RISC-V platform specification](https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc): the write hart use the __builtin__clear_cache or the syscall riscv_flush_icache directly after modifying code in riscv port, to execute fence.i on local hart and other harts by IPI. That's because fence.i only synchronizes the local hart, and the OS can reschedule the user hart to a different physical hart after the fence.i. > > "To order older stores before younger instruction fetches, user-level programs must use system supplied > library calls (e.g. GNU libc's __riscv_flush_icache, which invokes the Linux kernel's > corresponding vDSO routine), rather than executing the fence.i instruction directly." > > What now seems unnecessary is that we also put fence.i in front of code that will be modifed concurrently, just like Aarch64 port. Because the icache flush syscall already provides the explicit icache synchronization between all harts, so that we can remove fence.i used in the read hart. > Details of the discussion can be found in https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000571.html. > > In contrast, the isb in aarch64 is not broadcast by the writing PE, so any other PE must perform its own isb synchronization after it knows that the instruction update is visible. > > Tier1 of hotspot and jdk passed on unmatched. Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: add a data fence before clear cache ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9770/files - new: https://git.openjdk.org/jdk/pull/9770/files/c5b09d64..f6c8009c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9770&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9770&range=00-01 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9770.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9770/head:pull/9770 PR: https://git.openjdk.org/jdk/pull/9770 From dholmes at openjdk.org Mon Aug 8 02:58:58 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Aug 2022 02:58:58 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp In-Reply-To: <8uh4O1V5TnmKsKxB0blcohCIcM26deY35AKvEG11l_I=.1213fbe8-9793-46ee-9f6e-c2c82b55cfaf@github.com> References: <8uh4O1V5TnmKsKxB0blcohCIcM26deY35AKvEG11l_I=.1213fbe8-9793-46ee-9f6e-c2c82b55cfaf@github.com> Message-ID: On Mon, 8 Aug 2022 02:14:45 GMT, Ioi Lam wrote: > the above reason can be used against any sort of refactoring of the source code Indeed - they are always the "cons" of such a refactoring, and it is up to the "pros" to outweigh them. ------------- PR: https://git.openjdk.org/jdk/pull/9788 From yadongwang at openjdk.org Mon Aug 8 03:38:07 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Mon, 8 Aug 2022 03:38:07 GMT Subject: RFR: 8291893: riscv: remove fence.i used in user space [v3] In-Reply-To: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> References: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> Message-ID: > The usage of fence.i is in-efficient or redundant in the current implementation of riscv port now. The riscv port has already followed the [RISC-V platform specification](https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc): the write hart use the __builtin__clear_cache or the syscall riscv_flush_icache directly after modifying code in riscv port, to execute fence.i on local hart and other harts by IPI. That's because fence.i only synchronizes the local hart, and the OS can reschedule the user hart to a different physical hart after the fence.i. > > "To order older stores before younger instruction fetches, user-level programs must use system supplied > library calls (e.g. GNU libc's __riscv_flush_icache, which invokes the Linux kernel's > corresponding vDSO routine), rather than executing the fence.i instruction directly." > > What now seems unnecessary is that we also put fence.i in front of code that will be modifed concurrently, just like Aarch64 port. Because the icache flush syscall already provides the explicit icache synchronization between all harts, so that we can remove fence.i used in the read hart. > Details of the discussion can be found in https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000571.html. > > In contrast, the isb in aarch64 is not broadcast by the writing PE, so any other PE must perform its own isb synchronization after it knows that the instruction update is visible. > > Tier1 of hotspot and jdk passed on unmatched. Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: remove obsolete comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9770/files - new: https://git.openjdk.org/jdk/pull/9770/files/f6c8009c..ee13674d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9770&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9770&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9770.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9770/head:pull/9770 PR: https://git.openjdk.org/jdk/pull/9770 From fyang at openjdk.org Mon Aug 8 03:44:01 2022 From: fyang at openjdk.org (Fei Yang) Date: Mon, 8 Aug 2022 03:44:01 GMT Subject: RFR: 8291893: riscv: remove fence.i used in user space [v3] In-Reply-To: References: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> Message-ID: <_25BiFpWWoXyjeHKpNQhxdExRm9XrEksoXamBY_LtVA=.7efcae82-e4e1-40e4-9088-0447201ead25@github.com> On Mon, 8 Aug 2022 03:38:07 GMT, Yadong Wang wrote: >> The usage of fence.i is in-efficient or redundant in the current implementation of riscv port now. The riscv port has already followed the [RISC-V platform specification](https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc): the write hart use the __builtin__clear_cache or the syscall riscv_flush_icache directly after modifying code in riscv port, to execute fence.i on local hart and other harts by IPI. That's because fence.i only synchronizes the local hart, and the OS can reschedule the user hart to a different physical hart after the fence.i. >> >> "To order older stores before younger instruction fetches, user-level programs must use system supplied >> library calls (e.g. GNU libc's __riscv_flush_icache, which invokes the Linux kernel's >> corresponding vDSO routine), rather than executing the fence.i instruction directly." >> >> What now seems unnecessary is that we also put fence.i in front of code that will be modifed concurrently, just like Aarch64 port. Because the icache flush syscall already provides the explicit icache synchronization between all harts, so that we can remove fence.i used in the read hart. >> Details of the discussion can be found in https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000571.html. >> >> In contrast, the isb in aarch64 is not broadcast by the writing PE, so any other PE must perform its own isb synchronization after it knows that the instruction update is visible. >> >> Tier1 of hotspot and jdk passed on unmatched. > > Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: > > remove obsolete comments Updated change looks good. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/9770 From jwaters at openjdk.org Mon Aug 8 04:49:42 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 04:49:42 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys Message-ID: JLI_ReportErrorMessageSys has a number of issues, as listed below: - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated ------------- Commit messages: - Whitespace in Unix variant - Improve null termination - Fix formatting issues - Initial change to JLI_ReportErrorMessageSys Changes: https://git.openjdk.org/jdk/pull/9793/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292016 Stats: 66 lines in 4 files changed: 33 ins; 10 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/9793.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9793/head:pull/9793 PR: https://git.openjdk.org/jdk/pull/9793 From jwaters at openjdk.org Mon Aug 8 04:54:03 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 04:54:03 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v2] In-Reply-To: References: Message-ID: > JLI_ReportErrorMessageSys has a number of issues, as listed below: > > - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. > > - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. > > - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. > > - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. > > Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Try to make Skara happy with comment whitespaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9793/files - new: https://git.openjdk.org/jdk/pull/9793/files/845d94f0..fcf1f677 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9793.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9793/head:pull/9793 PR: https://git.openjdk.org/jdk/pull/9793 From jwaters at openjdk.org Mon Aug 8 05:04:10 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 05:04:10 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v3] In-Reply-To: References: Message-ID: <1QDwiRq6WMy-tMp6ctVRZfST5qX88BKGpSnb0Yjav5w=.a14cc1ee-0a90-4bfb-b70f-423927511484@github.com> > JLI_ReportErrorMessageSys has a number of issues, as listed below: > > - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. > > - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. > > - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. > > - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. > > Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Small Unix implementation refinement ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9793/files - new: https://git.openjdk.org/jdk/pull/9793/files/fcf1f677..ad74bbd0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9793.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9793/head:pull/9793 PR: https://git.openjdk.org/jdk/pull/9793 From jwaters at openjdk.org Mon Aug 8 05:08:28 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 05:08:28 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v4] In-Reply-To: References: Message-ID: <4km1B8MW2ZKGQUPBL5ahVDa0sbNuFPWziKDKfcTrkzU=.d092357e-7079-4b1c-b8ae-10d38c8903c2@github.com> > JLI_ReportErrorMessageSys has a number of issues, as listed below: > > - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. > > - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. > > - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. > > - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. > > Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Why does Skara hate me so much ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9793/files - new: https://git.openjdk.org/jdk/pull/9793/files/ad74bbd0..a0a7948d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9793.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9793/head:pull/9793 PR: https://git.openjdk.org/jdk/pull/9793 From jwaters at openjdk.org Mon Aug 8 05:12:13 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 05:12:13 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v5] In-Reply-To: References: Message-ID: > JLI_ReportErrorMessageSys has a number of issues, as listed below: > > - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. > > - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. > > - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. > > - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. > > Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Alright Skara, you win ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9793/files - new: https://git.openjdk.org/jdk/pull/9793/files/a0a7948d..6175df6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=03-04 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9793.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9793/head:pull/9793 PR: https://git.openjdk.org/jdk/pull/9793 From jwaters at openjdk.org Mon Aug 8 05:20:07 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 05:20:07 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v6] In-Reply-To: References: Message-ID: <5FiaJu3vZjuaLUZbvhmVqWZfBEUZTkfDR2xuLrexFuE=.62ae8e99-3b7b-4563-b25d-049974f66764@github.com> > JLI_ReportErrorMessageSys has a number of issues, as listed below: > > - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. > > - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. > > - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. > > - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. > > Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated Julian Waters has updated the pull request incrementally with one additional commit since the last revision: I don't even know anymore ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9793/files - new: https://git.openjdk.org/jdk/pull/9793/files/6175df6e..280942d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=04-05 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9793.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9793/head:pull/9793 PR: https://git.openjdk.org/jdk/pull/9793 From jwaters at openjdk.org Mon Aug 8 05:22:28 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 05:22:28 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v7] In-Reply-To: References: Message-ID: > JLI_ReportErrorMessageSys has a number of issues, as listed below: > > - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. > > - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. > > - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. > > - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. > > Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated Julian Waters has updated the pull request incrementally with one additional commit since the last revision: I feel stupid ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9793/files - new: https://git.openjdk.org/jdk/pull/9793/files/280942d0..e1594dbc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=05-06 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9793.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9793/head:pull/9793 PR: https://git.openjdk.org/jdk/pull/9793 From vkempik at openjdk.org Mon Aug 8 07:27:05 2022 From: vkempik at openjdk.org (Vladimir Kempik) Date: Mon, 8 Aug 2022 07:27:05 GMT Subject: RFR: 8291893: riscv: remove fence.i used in user space [v3] In-Reply-To: References: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> Message-ID: On Mon, 8 Aug 2022 03:38:07 GMT, Yadong Wang wrote: >> The usage of fence.i is in-efficient or redundant in the current implementation of riscv port now. The riscv port has already followed the [RISC-V platform specification](https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc): the write hart use the __builtin__clear_cache or the syscall riscv_flush_icache directly after modifying code in riscv port, to execute fence.i on local hart and other harts by IPI. That's because fence.i only synchronizes the local hart, and the OS can reschedule the user hart to a different physical hart after the fence.i. >> >> "To order older stores before younger instruction fetches, user-level programs must use system supplied >> library calls (e.g. GNU libc's __riscv_flush_icache, which invokes the Linux kernel's >> corresponding vDSO routine), rather than executing the fence.i instruction directly." >> >> What now seems unnecessary is that we also put fence.i in front of code that will be modifed concurrently, just like Aarch64 port. Because the icache flush syscall already provides the explicit icache synchronization between all harts, so that we can remove fence.i used in the read hart. >> Details of the discussion can be found in https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000571.html. >> >> In contrast, the isb in aarch64 is not broadcast by the writing PE, so any other PE must perform its own isb synchronization after it knows that the instruction update is visible. >> >> Tier1 of hotspot and jdk passed on unmatched. > > Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: > > remove obsolete comments LGTM ------------- Marked as reviewed by vkempik (Committer). PR: https://git.openjdk.org/jdk/pull/9770 From vkempik at openjdk.org Mon Aug 8 08:15:01 2022 From: vkempik at openjdk.org (Vladimir Kempik) Date: Mon, 8 Aug 2022 08:15:01 GMT Subject: RFR: 8291893: riscv: remove fence.i used in user space [v3] In-Reply-To: References: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> Message-ID: <5YAkrTMaTcibJwsrs6u054uW432phOg9MU9x0Vz7IOg=.0d0c359e-153d-4e30-b710-4654a3ff31d0@github.com> On Mon, 8 Aug 2022 03:38:07 GMT, Yadong Wang wrote: >> The usage of fence.i is in-efficient or redundant in the current implementation of riscv port now. The riscv port has already followed the [RISC-V platform specification](https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc): the write hart use the __builtin__clear_cache or the syscall riscv_flush_icache directly after modifying code in riscv port, to execute fence.i on local hart and other harts by IPI. That's because fence.i only synchronizes the local hart, and the OS can reschedule the user hart to a different physical hart after the fence.i. >> >> "To order older stores before younger instruction fetches, user-level programs must use system supplied >> library calls (e.g. GNU libc's __riscv_flush_icache, which invokes the Linux kernel's >> corresponding vDSO routine), rather than executing the fence.i instruction directly." >> >> What now seems unnecessary is that we also put fence.i in front of code that will be modifed concurrently, just like Aarch64 port. Because the icache flush syscall already provides the explicit icache synchronization between all harts, so that we can remove fence.i used in the read hart. >> Details of the discussion can be found in https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000571.html. >> >> In contrast, the isb in aarch64 is not broadcast by the writing PE, so any other PE must perform its own isb synchronization after it knows that the instruction update is visible. >> >> Tier1 of hotspot and jdk passed on unmatched. > > Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: > > remove obsolete comments Could you wait a little with the push please, I wanna compare few things on sifive ( or thead) before and after the patch. ------------- PR: https://git.openjdk.org/jdk/pull/9770 From yadongwang at openjdk.org Mon Aug 8 08:24:55 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Mon, 8 Aug 2022 08:24:55 GMT Subject: RFR: 8291893: riscv: remove fence.i used in user space [v3] In-Reply-To: <5YAkrTMaTcibJwsrs6u054uW432phOg9MU9x0Vz7IOg=.0d0c359e-153d-4e30-b710-4654a3ff31d0@github.com> References: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> <5YAkrTMaTcibJwsrs6u054uW432phOg9MU9x0Vz7IOg=.0d0c359e-153d-4e30-b710-4654a3ff31d0@github.com> Message-ID: On Mon, 8 Aug 2022 08:12:59 GMT, Vladimir Kempik wrote: > Could you wait a little with the push please, I wanna compare few things on sifive ( or thead) before and after the patch. Sure. ------------- PR: https://git.openjdk.org/jdk/pull/9770 From dholmes at openjdk.org Mon Aug 8 09:10:03 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Aug 2022 09:10:03 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v7] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 05:22:28 GMT, Julian Waters wrote: >> JLI_ReportErrorMessageSys has a number of issues, as listed below: >> >> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. >> >> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. >> >> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. >> >> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. >> >> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > I feel stupid src/java.base/unix/native/libjli/java_md_common.c line 209: > 207: /* > 208: * TODO: its safer to use strerror_r but is not available on > 209: * Solaris 8. Until then.... We are well past then :) so this should be changed to use strerror_r - though see ./java.base/unix/native/libjava/jni_util_md.c ------------- PR: https://git.openjdk.org/jdk/pull/9793 From vkempik at openjdk.org Mon Aug 8 09:33:23 2022 From: vkempik at openjdk.org (Vladimir Kempik) Date: Mon, 8 Aug 2022 09:33:23 GMT Subject: RFR: 8291893: riscv: remove fence.i used in user space [v3] In-Reply-To: References: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> Message-ID: On Mon, 8 Aug 2022 03:38:07 GMT, Yadong Wang wrote: >> The usage of fence.i is in-efficient or redundant in the current implementation of riscv port now. The riscv port has already followed the [RISC-V platform specification](https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc): the write hart use the __builtin__clear_cache or the syscall riscv_flush_icache directly after modifying code in riscv port, to execute fence.i on local hart and other harts by IPI. That's because fence.i only synchronizes the local hart, and the OS can reschedule the user hart to a different physical hart after the fence.i. >> >> "To order older stores before younger instruction fetches, user-level programs must use system supplied >> library calls (e.g. GNU libc's __riscv_flush_icache, which invokes the Linux kernel's >> corresponding vDSO routine), rather than executing the fence.i instruction directly." >> >> What now seems unnecessary is that we also put fence.i in front of code that will be modifed concurrently, just like Aarch64 port. Because the icache flush syscall already provides the explicit icache synchronization between all harts, so that we can remove fence.i used in the read hart. >> Details of the discussion can be found in https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000571.html. >> >> In contrast, the isb in aarch64 is not broadcast by the writing PE, so any other PE must perform its own isb synchronization after it knows that the instruction update is visible. >> >> Tier1 of hotspot and jdk passed on unmatched. > > Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: > > remove obsolete comments Ok, I have run renaisance philosophers on the thead and sifive with jdk before and after the patch. seeing significant perf improvement on thead, 5-8% , with the patch. On hifive 2-5% perf improvement. I can sponsor the commit if you want. ------------- PR: https://git.openjdk.org/jdk/pull/9770 From eosterlund at openjdk.org Mon Aug 8 10:17:30 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 8 Aug 2022 10:17:30 GMT Subject: RFR: 8290025: Remove the Sweeper [v7] In-Reply-To: References: Message-ID: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Polish comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9741/files - new: https://git.openjdk.org/jdk/pull/9741/files/29545778..07470c52 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9741/head:pull/9741 PR: https://git.openjdk.org/jdk/pull/9741 From yadongwang at openjdk.org Mon Aug 8 10:26:22 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Mon, 8 Aug 2022 10:26:22 GMT Subject: RFR: 8291893: riscv: remove fence.i used in user space [v3] In-Reply-To: References: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> Message-ID: On Mon, 8 Aug 2022 09:31:12 GMT, Vladimir Kempik wrote: > Ok, I have run renaisance philosophers on the thead and sifive with jdk before and after the patch. seeing significant perf improvement on thead, 5-8% , with the patch. On hifive 0-3% perf improvement. > > I can sponsor the commit if you want. Thansk a lot. Please help with the sponsor. ------------- PR: https://git.openjdk.org/jdk/pull/9770 From aph at openjdk.org Mon Aug 8 10:35:22 2022 From: aph at openjdk.org (Andrew Haley) Date: Mon, 8 Aug 2022 10:35:22 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call [v2] In-Reply-To: References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: On Fri, 5 Aug 2022 20:13:17 GMT, Evgeny Astigeevich wrote: >> `MacroAssembler::trampoline_call` can skip generation of a trampoline stub if C2 phase output is in the checking emitted code size mode. If it is not C2 compilation, `trampoline_call` always generates a trampoline stub. >> >> `gen_continuation_enter` as a part of C2 compilation needed to disable the functionality above. Now `trampoline_call` has the `check_emit_size` which allows to disable the functionality completely. Its default value is `true` which means the functionality is enabled. >> >> There are problems: >> - C2 specific code which must be properly guarded if it is not C2 compilation. The code has the risk of undefined behaviour (UB). It is done with `is_c2_compile`. [JDK-8291654](https://bugs.openjdk.org/browse/JDK-8291654) is an example of changes caused UB. >> - The default value of `check_emit_size`. The current value `true` allows C1 to access the C2 specific code. Setting the default value to `false` will require to review and to update every existing use of `trampoline_call`. It will complicate uses of `trampoline_call`: each time a decision needs to be done - use or not use the default. >> >> Summary of changes: >> - Have a virtual `emit_trampoline_stub` which is privately overridden in `C2_MacroAssembler`. The overridden version does not emit a stub if C2 phase output is in the checking emitted code size mode. >> - `emit_trampoline_stub` returns `bool` instead of `address` because `address` is only used to check the success of a call. >> - `check_emit_size` is removed because it is not needed any more. >> - `NativeCall::trampoline_jump`: >> - Changed to return `void` because the result is not used. It was returning the result of `emit_trampoline_stub`. >> - Assert `emit_trampoline_stub`. >> >> Tested with fastdebug/release builds: >> - `gtest`: Passed. >> - `tier1`...`tier4`: Passed. > > Evgeny Astigeevich has updated the pull request incrementally with three additional commits since the last revision: > > - Restore original NativeCall::trampoline_jump functionality > - Substitute entry.target() with target > - Remove unneeded assert This looks very wrong to me. We could usefully add trampolines to C1, and this just makes doing that more difficult. Why don't you just define is_c2_compilation() appropriately in macroAssembler? ------------- PR: https://git.openjdk.org/jdk/pull/9782 From aph at openjdk.org Mon Aug 8 10:41:10 2022 From: aph at openjdk.org (Andrew Haley) Date: Mon, 8 Aug 2022 10:41:10 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call [v2] In-Reply-To: References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: On Mon, 8 Aug 2022 10:33:15 GMT, Andrew Haley wrote: > Why don't you just define is_c2_compilation() appropriately in macroAssembler? Or (better) `in_scratch_emit_size()`? That's the semantics we want. ------------- PR: https://git.openjdk.org/jdk/pull/9782 From chagedorn at openjdk.org Mon Aug 8 11:00:50 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 8 Aug 2022 11:00:50 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v14] In-Reply-To: References: Message-ID: > When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: > > Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 > V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec > V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 > V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df > V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 > V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d > V [libjvm.so+0x12091c9] JavaThread::run()+0x167 > V [libjvm.so+0x1206ada] Thread::call_run()+0x180 > V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f > > This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. > > This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): > > Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) > V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) > V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) > V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) > V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) > V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) > V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) > V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) > V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) > > For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. > > The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf > I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. > > The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. > > Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. > > **Testing:** > Apart from manual testing, I've added two kinds of tests: > - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. > - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. > > On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. > > To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. > > I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). > > Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! > > Thanks, > Christian Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits: - Fix optimized build - Merge branch 'master' into JDK-8242181 - Merge branch 'master' into JDK-8242181 - Exclude TestDwarf.java when run with product because TraceDwarf is a develop flag - Merge branch 'master' into JDK-8242181 - Merge branch 'master' into JDK-8242181 - Fix TestDwarf for older GCC versions - Change logging from UL to tty based with new TraceDwarfLevel develop flag - Add support to parse the .debug_line section in DWARF 2 as emitted by GCC 8, add some comments - Merge branch 'master' into JDK-8242181 - ... and 61 more: https://git.openjdk.org/jdk/compare/20123ea4...d5dc4694 ------------- Changes: https://git.openjdk.org/jdk/pull/7126/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=7126&range=13 Stats: 2782 lines in 18 files changed: 2686 ins; 41 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/7126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/7126/head:pull/7126 PR: https://git.openjdk.org/jdk/pull/7126 From eosterlund at openjdk.org Mon Aug 8 11:04:24 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 8 Aug 2022 11:04:24 GMT Subject: RFR: 8290025: Remove the Sweeper [v6] In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 00:17:39 GMT, Coleen Phillimore wrote: >> Erik ?sterlund 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 8290025_remove_sweeper >> - Removed more stale things >> - Remove incorrect comment >> - Feedback v2 >> - Feedback v1 >> - 8290025: Remove the Sweeper > > src/hotspot/share/code/codeCache.cpp line 984: > >> 982: nm->flush(); >> 983: if (next == nm) { >> 984: // Self looped means end of list > > Why not nullptr for the end of the list? Because inline caches. When the end is self looped instead of null, I can check if an nmethod is on the list or not, which is used to ensure that unlinking of an nmethod during class unloading happens only once. Why would it ever happen twice? Because the task that unlinks nmethod might have to restart due to inline cache cleaning failing due to running out of ICStubs. And when the code cache is walked the second time, I don't want to call unlink again if we already did that the first traversal. That's why the end of list is self looped instead of null. > src/hotspot/share/code/codeCache.cpp line 1312: > >> 1310: CompiledMethod* cm = old_compiled_method_table->at(i); >> 1311: // Only walk !is_unloading nmethods, the other ones will get removed by the GC. >> 1312: if (!cm->is_unloading()) { > > I thought we were going to walk the unloading methods? Or should that be another bug fix? It's unlikely to ever find a reproducer so I wouldn't mind if it was fixed with this giant patch. You are correct. However, I think the bug fix should be in a separate bug fix, and not in this RFE. > src/hotspot/share/code/nmethod.cpp line 1316: > >> 1314: >> 1315: // Change state >> 1316: bool success = try_transition(not_entrant); > > I suppose in a further RFE, you could rename try_transition or do the transition inline. Does it still CAS? It no longer does CAS because we always told the CompiledMethod_lock now when fiddling with this transition. The transition from not_installed to in_use can still fail, if the nmethod became not_entrant before it became in_use. I think the not_installed state can be removed altogether, but I think that's a separate RFE. > src/hotspot/share/code/nmethod.hpp line 268: > >> 266: >> 267: // Protected by CompiledMethod_lock >> 268: volatile signed char _state; // {not_installed, in_use, not_entrant} > > There's a fourth state: not_used which you might as well add to the comment ? Fixed! > src/hotspot/share/oops/constantPool.cpp line 2222: > >> 2220: } >> 2221: >> 2222: // If the condition below is true, it means that the nmethod was found to > > I think this comment should say Method and not nmethod. I think this was a cut and paste error. I assume that the is_maybe_on_stack is generalizing "stack" meaning on the execution OR continuation stack ? I think it really does reference nmethod::is_maybe_on_stack(), and explains that the logic for ConstantPool::is_maybe_on_stack works "similar" to how it works for nmethods. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Mon Aug 8 11:04:28 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 8 Aug 2022 11:04:28 GMT Subject: RFR: 8290025: Remove the Sweeper [v7] In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 00:27:25 GMT, Coleen Phillimore wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Polish comment > > src/hotspot/share/code/nmethod.cpp line 1712: > >> 1710: mark_as_seen_on_stack(); >> 1711: } >> 1712: > > Thank you! It's nice to see this code which still may have bugs removed. I'm glad you like it! ------------- PR: https://git.openjdk.org/jdk/pull/9741 From yadongwang at openjdk.org Mon Aug 8 11:50:44 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Mon, 8 Aug 2022 11:50:44 GMT Subject: Integrated: 8291893: riscv: remove fence.i used in user space In-Reply-To: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> References: <3xEs5r_5gbAFL7GH35QkkwCelUhyrVnL9hTrgirprkM=.c5db5d6a-f890-4110-86a8-adfde798cb33@github.com> Message-ID: <13FCJF1DMkYXVDD3TSz6WZE1Ln6Do8fi_OIcdi4FtiE=.acd4afa5-0a1e-49f1-9339-464804989fc4@github.com> On Fri, 5 Aug 2022 09:37:54 GMT, Yadong Wang wrote: > The usage of fence.i is in-efficient or redundant in the current implementation of riscv port now. The riscv port has already followed the [RISC-V platform specification](https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc): the write hart use the __builtin__clear_cache or the syscall riscv_flush_icache directly after modifying code in riscv port, to execute fence.i on local hart and other harts by IPI. That's because fence.i only synchronizes the local hart, and the OS can reschedule the user hart to a different physical hart after the fence.i. > > "To order older stores before younger instruction fetches, user-level programs must use system supplied > library calls (e.g. GNU libc's __riscv_flush_icache, which invokes the Linux kernel's > corresponding vDSO routine), rather than executing the fence.i instruction directly." > > What now seems unnecessary is that we also put fence.i in front of code that will be modifed concurrently, just like Aarch64 port. Because the icache flush syscall already provides the explicit icache synchronization between all harts, so that we can remove fence.i used in the read hart. > Details of the discussion can be found in https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000571.html. > > In contrast, the isb in aarch64 is not broadcast by the writing PE, so any other PE must perform its own isb synchronization after it knows that the instruction update is visible. > > Tier1 of hotspot and jdk passed on unmatched. This pull request has now been integrated. Changeset: 5a539e8d Author: Yadong Wang Committer: Vladimir Kempik URL: https://git.openjdk.org/jdk/commit/5a539e8da7dbea1eaa10d799f75199ea359f7a22 Stats: 77 lines in 10 files changed: 8 ins; 63 del; 6 mod 8291893: riscv: remove fence.i used in user space Reviewed-by: fyang, vkempik ------------- PR: https://git.openjdk.org/jdk/pull/9770 From jwaters at openjdk.org Mon Aug 8 12:14:50 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 12:14:50 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v8] In-Reply-To: References: Message-ID: <2OnifFOcbnhbF_Zmdw_9jOBXb_fm0fUpXGfCrxjtAU4=.c5fda5a4-7a1d-4df2-b7af-71f732587f5a@github.com> > JLI_ReportErrorMessageSys has a number of issues, as listed below: > > - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. > > - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. > > - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. > > - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. > > Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - Whitespace - Resolve Windows compile error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9793/files - new: https://git.openjdk.org/jdk/pull/9793/files/e1594dbc..723557e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=06-07 Stats: 8 lines in 1 file changed: 1 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9793.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9793/head:pull/9793 PR: https://git.openjdk.org/jdk/pull/9793 From hseigel at openjdk.org Mon Aug 8 12:19:06 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 8 Aug 2022 12:19:06 GMT Subject: RFR: 8291459: JVM crash with GenerateOopMap::error_work(char const*, __va_list_tag*) [v3] In-Reply-To: References: Message-ID: <52o4MIHURG2x92Px78PDi8rocPGw-T6SlCNIe6ctzUg=.8f897f51-9616-4bfe-9d4f-e535b9830da7@github.com> On Fri, 5 Aug 2022 13:44:05 GMT, Harold Seigel wrote: >> The JVM fails when generating oop maps for method getAlphanumericCode(int) in bug_file/com/google/zxing/qrcode/encoder/Encoder.javap because the last bytecode in the method is an unreachable conditional branch at byecode index 11131: >> >> 11124: ireturn >> 11125: iinc 41, 1 >> 11128: iload 41 >> 11130: iconst_2 >> 11131: if_icmple 291 >> >> The class file (Encoder.class) containing getAlphanumericCode(int) has a class file version of 49. So it is verified by the old verifier, which allows methods to end in a conditional branch provided that the conditional branch is unreachable during method execution. >> >> This fix changes GenerateOopMap::jump_targets_do() to handle such methods. >> >> The fix was tested by running the user's failing program, the new regression test, Mach5 tiers 1-2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linu x64, and the JC Lang,VM, and API tests locally on Linux x64. >> >> Please review. >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > remove packages from test classes Thanks David and Coleen for the reviews. ------------- PR: https://git.openjdk.org/jdk/pull/9745 From hseigel at openjdk.org Mon Aug 8 12:23:14 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 8 Aug 2022 12:23:14 GMT Subject: Integrated: 8291459: JVM crash with GenerateOopMap::error_work(char const*, __va_list_tag*) In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 14:29:23 GMT, Harold Seigel wrote: > The JVM fails when generating oop maps for method getAlphanumericCode(int) in bug_file/com/google/zxing/qrcode/encoder/Encoder.javap because the last bytecode in the method is an unreachable conditional branch at byecode index 11131: > > 11124: ireturn > 11125: iinc 41, 1 > 11128: iload 41 > 11130: iconst_2 > 11131: if_icmple 291 > > The class file (Encoder.class) containing getAlphanumericCode(int) has a class file version of 49. So it is verified by the old verifier, which allows methods to end in a conditional branch provided that the conditional branch is unreachable during method execution. > > This fix changes GenerateOopMap::jump_targets_do() to handle such methods. > > The fix was tested by running the user's failing program, the new regression test, Mach5 tiers 1-2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linu x64, and the JC Lang,VM, and API tests locally on Linux x64. > > Please review. > Thanks, Harold This pull request has now been integrated. Changeset: 8d88be23 Author: Harold Seigel URL: https://git.openjdk.org/jdk/commit/8d88be233bc0d27d78e51c4eff0ba1ee47f4617a Stats: 115 lines in 3 files changed: 114 ins; 0 del; 1 mod 8291459: JVM crash with GenerateOopMap::error_work(char const*, __va_list_tag*) Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/9745 From jwaters at openjdk.org Mon Aug 8 12:29:09 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 12:29:09 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v7] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 09:06:39 GMT, David Holmes wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> I feel stupid > > src/java.base/unix/native/libjli/java_md_common.c line 209: > >> 207: /* >> 208: * TODO: its safer to use strerror_r but is not available on >> 209: * Solaris 8. Until then.... > > We are well past then :) so this should be changed to use strerror_r - though see ./java.base/unix/native/libjava/jni_util_md.c Looks like the names in jni_util_md.c are also hopelessly inaccurate - what would equate to strlen(strerror_r(errno)) and returns a size_t is named getLastErrorString :P ------------- PR: https://git.openjdk.org/jdk/pull/9793 From ihse at openjdk.org Mon Aug 8 12:50:13 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 8 Aug 2022 12:50:13 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jul 2022 14:18:49 GMT, Jorn Vernee wrote: >> This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. i.e. it is not meant as a long term solution, but as a way of allowing incremental progress. >> >> Out of the ~1100 files that make up hotspot on Windows x64 , ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. >> >> Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. >> >> I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files, so I wanted to gather feedback on this approach before continuing with that. >> >> --- >> >> To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: >> >> PRAGMA_DIAG_PUSH >> PRAGMA_ALLOW_LOSSY_CONVERSIONS >> >> And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: >> >> PRAGMA_DIAG_POP >> >> 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. >> >> [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge branch 'master' into Warn_Narrow > - Polish pt2 > - Polish > - Remove PUSH POP from test files > - Remove PUSH POP from cpp files > - Rest of the tests > - More test > - AArch64 > - Disable for tests > - Fix apostrophe > - ... and 5 more: https://git.openjdk.org/jdk/compare/1c055076...fb276afd While I normally appreciate enabling warnings, and fixing them, I tend to side a bit with David on this one. There is a lot of `PRAGMA_ALLOW_LOSSY_CONVERSIONS` in this PR, injected into the files, forever to be forgotten. I do agree with @JornVernee that warnings are in a bit of a bind; if we really think a warning is useful, but it has been historically turned off, it is a huge uphill battle to get it enabled, by fixing all historical issues at once. This results in warnings being left turned off, even for new code, since no-one has the time available to address all issues at once. I'm thinking that part of this problem is due to the lack of granularity that the build systems offers to enable/disable warnings. We have a "global" enable, and then we have a "per dll" disable. It would not be too hard for me to modify this, so we could make a list of source files for which the conversion warning still needs to be turned off. If this is a coherent list in a single make file, it is much easier to see what remains to be done to actually fix these issues. (This will not work for .hpp files; these will still need the pragma push/pop thing, and should therefore be prioritized when actually fixing this.) Still, the warnings need to be fixed (or the list will need to be kept indefinitely, which is of course also a valid solution). And we need to be prepared to put in effort to actually resolve these, if we really want this to happen. ------------- PR: https://git.openjdk.org/jdk/pull/9516 From duke at openjdk.org Mon Aug 8 13:02:10 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Aug 2022 13:02:10 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v5] In-Reply-To: References: <5JfLyDDTi0H7WRva8W0WV7hI3xKvxVo7mPyaWzpx1pw=.a682010e-356f-4972-a343-a2058fa2b2ef@github.com> Message-ID: On Sat, 6 Aug 2022 04:14:01 GMT, Dean Long wrote: >> The compiler dependencies are protecting against loading of a class that is a subtype of X. If X is unloaded, then we can be pretty sure nobody is going to load a subclass of X. > > Isn't there something we can assert about the state of these nmethods? Maybe unlinked and !in_use? Seems like the culprit it `CodeCache::UnloadingScope`. Currently the CodeCache::UnloadingScope does not encompass the klass unloading (different for each GC, some do some don't). Only the CodeCache unloading. This means that the is_unloading data is not up to date. After modifying serial to have the `UnloadingScope` covering both klass unloading and nmethod unloading this code seems to work. ```C++ void DependencyContext::remove_all_dependents() { nmethodBucket* b = dependencies_not_unloading(); set_dependencies(NULL); assert(b == nullptr, "All dependents should be unloading"); } The options here are to either fix the scopes for all GCs so it covers both, or introduce a slow `is_unloading` for the assert which does not use the cached unloading value. The second option still need to be GC aware as it requires the GCs notion of `is_alive`. The first option seems the best as it will be more correct with respect to the internal vm state. It will probably be better at catching future bugs as well. ------------- PR: https://git.openjdk.org/jdk/pull/9713 From iwalulya at openjdk.org Mon Aug 8 13:09:05 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 8 Aug 2022 13:09:05 GMT Subject: RFR: 8290357: Drop HeapRegion::marked_bytes() [v3] In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 09:45:15 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this removal of the `HeapRegion::_marked_bytes` member that records the bytes marked below tams in the recent mark as it is not really interesting in the removed places. I added comments to give reasons for this removal in the particular places for your review. >> >> Testing: jtreg gc/g1, gha >> >> Thanks, >> Thomas > > Thomas Schatzl 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 8290357-remove-marked-bytes > - Remove actual member and references > - initial version, use live_bytes instead of marked_bytes Lgtm! ------------- Marked as reviewed by iwalulya (Reviewer). PR: https://git.openjdk.org/jdk/pull/9511 From jwaters at openjdk.org Mon Aug 8 13:21:17 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 13:21:17 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v8] In-Reply-To: <2OnifFOcbnhbF_Zmdw_9jOBXb_fm0fUpXGfCrxjtAU4=.c5fda5a4-7a1d-4df2-b7af-71f732587f5a@github.com> References: <2OnifFOcbnhbF_Zmdw_9jOBXb_fm0fUpXGfCrxjtAU4=.c5fda5a4-7a1d-4df2-b7af-71f732587f5a@github.com> Message-ID: On Mon, 8 Aug 2022 12:14:50 GMT, Julian Waters wrote: >> JLI_ReportErrorMessageSys has a number of issues, as listed below: >> >> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. >> >> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. >> >> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. >> >> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. >> >> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated > > Julian Waters has updated the pull request incrementally with two additional commits since the last revision: > > - Whitespace > - Resolve Windows compile error Force push due to some accidental breaking changes ------------- PR: https://git.openjdk.org/jdk/pull/9793 From jwaters at openjdk.org Mon Aug 8 13:21:20 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 13:21:20 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v7] In-Reply-To: References: Message-ID: <7xJ7fc3kv-Qdu9PsisKq9EJjBki02DAGw39pDiqN7dQ=.dcd79a68-440a-4efe-9681-44f37d207cb7@github.com> On Mon, 8 Aug 2022 09:06:39 GMT, David Holmes wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> I feel stupid > > src/java.base/unix/native/libjli/java_md_common.c line 209: > >> 207: /* >> 208: * TODO: its safer to use strerror_r but is not available on >> 209: * Solaris 8. Until then.... > > We are well past then :) so this should be changed to use strerror_r - though see ./java.base/unix/native/libjava/jni_util_md.c Using getLastErrorString in the implementation for Unix, the Windows version of getLastErrorString is also broken, just like JLI_ErrorMessageSys, but unlike the latter shared code does use it, so no attempts will be made to fix it ------------- PR: https://git.openjdk.org/jdk/pull/9793 From jwaters at openjdk.org Mon Aug 8 13:25:22 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 13:25:22 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v9] In-Reply-To: References: Message-ID: > JLI_ReportErrorMessageSys has a number of issues, as listed below: > > - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. > > - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. > > - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. > > - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. > > Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated Julian Waters has updated the pull request incrementally with one additional commit since the last revision: getLastErrorString can be used for Unix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9793/files - new: https://git.openjdk.org/jdk/pull/9793/files/723557e3..98017b65 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=07-08 Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9793.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9793/head:pull/9793 PR: https://git.openjdk.org/jdk/pull/9793 From jwaters at openjdk.org Mon Aug 8 13:25:23 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 13:25:23 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v8] In-Reply-To: <2OnifFOcbnhbF_Zmdw_9jOBXb_fm0fUpXGfCrxjtAU4=.c5fda5a4-7a1d-4df2-b7af-71f732587f5a@github.com> References: <2OnifFOcbnhbF_Zmdw_9jOBXb_fm0fUpXGfCrxjtAU4=.c5fda5a4-7a1d-4df2-b7af-71f732587f5a@github.com> Message-ID: On Mon, 8 Aug 2022 12:14:50 GMT, Julian Waters wrote: >> JLI_ReportErrorMessageSys has a number of issues, as listed below: >> >> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. >> >> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. >> >> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. >> >> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. >> >> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated > > Julian Waters has updated the pull request incrementally with two additional commits since the last revision: > > - Whitespace > - Resolve Windows compile error Sorry bot, made a bit of a mistake... ------------- PR: https://git.openjdk.org/jdk/pull/9793 From tschatzl at openjdk.org Mon Aug 8 13:31:28 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 8 Aug 2022 13:31:28 GMT Subject: RFR: 8290357: Drop HeapRegion::marked_bytes() [v3] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 17:29:45 GMT, Sangheon Kim wrote: >> Thomas Schatzl 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 8290357-remove-marked-bytes >> - Remove actual member and references >> - initial version, use live_bytes instead of marked_bytes > > Looks good. > Just minor nit regarding the remaining comment of _marked_bytes. Thanks @sangheon @walulyai for your reviews ------------- PR: https://git.openjdk.org/jdk/pull/9511 From tschatzl at openjdk.org Mon Aug 8 13:31:29 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 8 Aug 2022 13:31:29 GMT Subject: Integrated: 8290357: Drop HeapRegion::marked_bytes() In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 11:06:27 GMT, Thomas Schatzl wrote: > Hi all, > > please review this removal of the `HeapRegion::_marked_bytes` member that records the bytes marked below tams in the recent mark as it is not really interesting in the removed places. I added comments to give reasons for this removal in the particular places for your review. > > Testing: jtreg gc/g1, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 45919371 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/459193710f0b8859cff364d7de3765c6dc4e08d8 Stats: 52 lines in 8 files changed: 0 ins; 40 del; 12 mod 8290357: Drop HeapRegion::marked_bytes() Reviewed-by: sangheki, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/9511 From stuefe at openjdk.org Mon Aug 8 13:51:37 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 8 Aug 2022 13:51:37 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v9] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 13:25:22 GMT, Julian Waters wrote: >> JLI_ReportErrorMessageSys has a number of issues, as listed below: >> >> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. >> >> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. >> >> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. >> >> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. >> >> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > getLastErrorString can be used for Unix Hi Julien, Just a tip: as long as you are in the active development phase of a patch, you can mark the PR as "draft". That way you do not spam the mailing lists with updates for every single push. And you save valuable Reviewer cycles since they won't have to look at the half-finished review. Once you are content with the patch, and all tests are green, you can mark the PR as "ready for review". Only then Review mails are sent out. --- That said, I don't think printing both codes really works. See my comment in JBS. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/9793 From jwaters at openjdk.org Mon Aug 8 14:12:01 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 14:12:01 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10] In-Reply-To: References: Message-ID: > JLI_ReportErrorMessageSys has a number of issues, as listed below: > > - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. > > - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. > > - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. > > - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. > > Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated Julian Waters has updated the pull request incrementally with one additional commit since the last revision: How did I even miss this?? ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9793/files - new: https://git.openjdk.org/jdk/pull/9793/files/98017b65..21675f31 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9793.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9793/head:pull/9793 PR: https://git.openjdk.org/jdk/pull/9793 From jvernee at openjdk.org Mon Aug 8 14:24:06 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 Aug 2022 14:24:06 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v4] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 12:47:52 GMT, Magnus Ihse Bursie wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Merge branch 'master' into Warn_Narrow >> - Polish pt2 >> - Polish >> - Remove PUSH POP from test files >> - Remove PUSH POP from cpp files >> - Rest of the tests >> - More test >> - AArch64 >> - Disable for tests >> - Fix apostrophe >> - ... and 5 more: https://git.openjdk.org/jdk/compare/1c055076...fb276afd > > While I normally appreciate enabling warnings, and fixing them, I tend to side a bit with David on this one. There is a lot of `PRAGMA_ALLOW_LOSSY_CONVERSIONS` in this PR, injected into the files, forever to be forgotten. > > I do agree with @JornVernee that warnings are in a bit of a bind; if we really think a warning is useful, but it has been historically turned off, it is a huge uphill battle to get it enabled, by fixing all historical issues at once. This results in warnings being left turned off, even for new code, since no-one has the time available to address all issues at once. > > I'm thinking that part of this problem is due to the lack of granularity that the build systems offers to enable/disable warnings. We have a "global" enable, and then we have a "per dll" disable. > > It would not be too hard for me to modify this, so we could make a list of source files for which the conversion warning still needs to be turned off. If this is a coherent list in a single make file, it is much easier to see what remains to be done to actually fix these issues. (This will not work for .hpp files; these will still need the pragma push/pop thing, and should therefore be prioritized when actually fixing this.) > > Still, the warnings need to be fixed (or the list will need to be kept indefinitely, which is of course also a valid solution). And we need to be prepared to put in effort to actually resolve these, if we really want this to happen. Thanks @magicus turning off warnings in a side file also seems like a decent solution. I think part of the problem with tackling all warnings at once is that it's (too) hard to decide whether it's worth doing, since there's such a huge volume of warnings. It's much easier to decide that for a couple of files, and then put in the work. i.e. employ a divide and conquer strategy. Maybe some of the warnings will never be fixed, because it just isn't worth the effort in some cases. But, this still seems better than globally disabling the warning to me. I think it's mostly an organizational/workflow issue, rather than a technical one. ------------- PR: https://git.openjdk.org/jdk/pull/9516 From duke at openjdk.org Mon Aug 8 15:25:55 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Mon, 8 Aug 2022 15:25:55 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call [v3] In-Reply-To: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: > `MacroAssembler::trampoline_call` can skip generation of a trampoline stub if C2 phase output is in the checking emitted code size mode. If it is not C2 compilation, `trampoline_call` always generates a trampoline stub. > > `gen_continuation_enter` as a part of C2 compilation needed to disable the functionality above. Now `trampoline_call` has the `check_emit_size` which allows to disable the functionality completely. Its default value is `true` which means the functionality is enabled. > > There are problems: > - C2 specific code which must be properly guarded if it is not C2 compilation. The code has the risk of undefined behaviour (UB). It is done with `is_c2_compile`. [JDK-8291654](https://bugs.openjdk.org/browse/JDK-8291654) is an example of changes caused UB. > - The default value of `check_emit_size`. The current value `true` allows C1 to access the C2 specific code. Setting the default value to `false` will require to review and to update every existing use of `trampoline_call`. It will complicate uses of `trampoline_call`: each time a decision needs to be done - use or not use the default. > > Summary of changes: > - Have a virtual `in_scratch_emit_size` returning `false` by default. It is privately overridden in `C2_MacroAssembler`. The overridden version returns `true` if C2 phase output is in the checking emitted code size mode. > - `check_emit_size` is removed because it is not needed any more. > > Tested with fastdebug/release builds: > - `gtest`: Passed. > - `tier1`...`tier4`: Passed. Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Add virtual in_scratch_emit_size instead of emit_trampoline_stub ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9782/files - new: https://git.openjdk.org/jdk/pull/9782/files/2e5e4aee..71a1ef00 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9782&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9782&range=01-02 Stats: 36 lines in 6 files changed: 10 ins; 8 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/9782.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9782/head:pull/9782 PR: https://git.openjdk.org/jdk/pull/9782 From duke at openjdk.org Mon Aug 8 15:25:56 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Mon, 8 Aug 2022 15:25:56 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call [v2] In-Reply-To: References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: On Mon, 8 Aug 2022 10:37:32 GMT, Andrew Haley wrote: > > Why don't you just define is_c2_compilation() appropriately in macroAssembler? > > Or (better) `in_scratch_emit_size()`? That's the semantics we want. Thank you for the suggestion. It's better. I rewrote the code to use `in_scratch_emit_size()`. ------------- PR: https://git.openjdk.org/jdk/pull/9782 From lmesnik at openjdk.org Mon Aug 8 15:36:35 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 8 Aug 2022 15:36:35 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v2] In-Reply-To: References: Message-ID: On Sun, 7 Aug 2022 12:50:42 GMT, Ramkumar Sunderbabu wrote: >> Tested with all GC options > > Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: > > 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java line 96: > 94: int iteration = 0; > 95: > 96: while (stresser.continueExecution()) { This loop never completes, while the goal is to produce some garbage and trigger GC. test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java line 98: > 96: while (stresser.continueExecution()) { > 97: while (iteration++ < YOUNG_GC_ITERATIONS) { > 98: byteArrayProducer.create(memChunk); it is needed to create at least some old objects which live after young GC. I propose to add 'tmp = byteArrayProducer.create(memChunk);' and free this tmp variable tight before WB.fullGC(). So we will have objects with different age (up to to 100). ------------- PR: https://git.openjdk.org/jdk/pull/9658 From rsunderbabu at openjdk.org Mon Aug 8 15:36:35 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Mon, 8 Aug 2022 15:36:35 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v2] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 15:28:49 GMT, Leonid Mesnik wrote: >> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: >> >> 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" > > test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java line 96: > >> 94: int iteration = 0; >> 95: >> 96: while (stresser.continueExecution()) { > > This loop never completes, while the goal is to produce some garbage and trigger GC. stresser runs for the duration of the test, I believe. Loop completes when test duration is complete. ------------- PR: https://git.openjdk.org/jdk/pull/9658 From duke at openjdk.org Mon Aug 8 15:38:58 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Aug 2022 15:38:58 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v6] In-Reply-To: References: Message-ID: > @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) > > Description from the original issue: >> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >> >> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >> >> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. > > Testing: Tier 1-7 Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Extend CodeCache::UnloadingScope to include klass unloading ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9713/files - new: https://git.openjdk.org/jdk/pull/9713/files/f8eaa683..019d4d1c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=04-05 Stats: 32 lines in 16 files changed: 5 ins; 10 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/9713.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9713/head:pull/9713 PR: https://git.openjdk.org/jdk/pull/9713 From duke at openjdk.org Mon Aug 8 15:40:21 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Aug 2022 15:40:21 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v5] In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 13:36:51 GMT, Axel Boldt-Christmas wrote: >> @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) >> >> Description from the original issue: >>> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >>> >>> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >>> >>> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. >> >> Testing: Tier 1-7 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Remove double counting _perf_total_buckets_deallocated_count Extended the UnloadingScope. Seems to work for tier 1-3. Will test tier 1-7 ------------- PR: https://git.openjdk.org/jdk/pull/9713 From lmesnik at openjdk.org Mon Aug 8 15:43:06 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 8 Aug 2022 15:43:06 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v2] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 15:34:10 GMT, Ramkumar Sunderbabu wrote: >> test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java line 96: >> >>> 94: int iteration = 0; >>> 95: >>> 96: while (stresser.continueExecution()) { >> >> This loop never completes, while the goal is to produce some garbage and trigger GC. > > stresser runs for the duration of the test, I believe. Loop completes when test duration is complete. ough, yes, I mean that loop was completed only once, so we have only one iteration per test, while the goal is to run a lot of lock/GC/unlock iterations. ------------- PR: https://git.openjdk.org/jdk/pull/9658 From rsunderbabu at openjdk.org Mon Aug 8 15:53:04 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Mon, 8 Aug 2022 15:53:04 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v2] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 15:39:32 GMT, Leonid Mesnik wrote: >> stresser runs for the duration of the test, I believe. Loop completes when test duration is complete. > > ough, yes, I mean that loop was completed only once, so we have only one iteration per test, while the goal is to run a lot of lock/GC/unlock iterations. Loop won't run for just once. It will run for the duration of the test. If the test is configured to run, say, 2 mins, stresser.continueExecution() will be false after 2 mins. ------------- PR: https://git.openjdk.org/jdk/pull/9658 From lmesnik at openjdk.org Mon Aug 8 16:02:20 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 8 Aug 2022 16:02:20 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v2] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 15:49:51 GMT, Ramkumar Sunderbabu wrote: >> ough, yes, I mean that loop was completed only once, so we have only one iteration per test, while the goal is to run a lot of lock/GC/unlock iterations. > > Loop won't run for just once. It will run for the duration of the test. If the test is configured to run, say, 2 mins, stresser.continueExecution() will be false after 2 mins. exactly, however, the whole 'engageGC' method will be executed only once and always work in this loop. So the combination of lock/engageGC()/unlock is executed only once and the test spends all it's time in 'engageGC' which is not the stress for lock/unlock and moreover could cause OOME if lock/unlock really locks GC. ------------- PR: https://git.openjdk.org/jdk/pull/9658 From rsunderbabu at openjdk.org Mon Aug 8 16:08:02 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Mon, 8 Aug 2022 16:08:02 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v2] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 15:58:06 GMT, Leonid Mesnik wrote: >> Loop won't run for just once. It will run for the duration of the test. If the test is configured to run, say, 2 mins, stresser.continueExecution() will be false after 2 mins. > > exactly, however, the whole 'engageGC' method will be executed only once and always work in this loop. > So the combination of lock/engageGC()/unlock is executed only once and the test spends all it's time in 'engageGC' which is not the stress for lock/unlock and moreover could cause OOME if lock/unlock really locks GC. so this is the algorithm you are getting at? while( test.duration ) { lock engageGC (100 youngGC and 1 fullGC) unlock } ------------- PR: https://git.openjdk.org/jdk/pull/9658 From lmesnik at openjdk.org Mon Aug 8 16:20:28 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 8 Aug 2022 16:20:28 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v2] In-Reply-To: References: Message-ID: <7g_cdjbE4sMT3qmq1uFA6uHGkq4HWZFnKTEyJMl0ys8=.d03f43c6-5a64-4095-a9a6-9e9ac985023d@github.com> On Mon, 8 Aug 2022 16:04:19 GMT, Ramkumar Sunderbabu wrote: >> exactly, however, the whole 'engageGC' method will be executed only once and always work in this loop. >> So the combination of lock/engageGC()/unlock is executed only once and the test spends all it's time in 'engageGC' which is not the stress for lock/unlock and moreover could cause OOME if lock/unlock really locks GC. > > so this is the algorithm you are getting at? > while( test.duration ) { > lock > engageGC (100 youngGC and 1 fullGC) > unlock > } Yes. It is what test should do. ------------- PR: https://git.openjdk.org/jdk/pull/9658 From jwaters at openjdk.org Mon Aug 8 16:25:41 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 16:25:41 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v11] In-Reply-To: References: Message-ID: > JLI_ReportErrorMessageSys has a number of issues, as listed below: > > - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. > > - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. > > - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. > > - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. > > Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Include jni_util.h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9793/files - new: https://git.openjdk.org/jdk/pull/9793/files/21675f31..c166e551 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=09-10 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9793.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9793/head:pull/9793 PR: https://git.openjdk.org/jdk/pull/9793 From jwaters at openjdk.org Mon Aug 8 17:15:08 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 17:15:08 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v11] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 16:25:41 GMT, Julian Waters wrote: >> JLI_ReportErrorMessageSys has a number of issues, as listed below: >> >> - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. >> >> - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. >> >> - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. >> >> - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. >> >> Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated > > Julian Waters has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. Alright Skara, I'm really sorry but don't lynch me for what I'm about to do... ------------- PR: https://git.openjdk.org/jdk/pull/9793 From duke at openjdk.org Mon Aug 8 17:31:31 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Aug 2022 17:31:31 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v7] In-Reply-To: References: Message-ID: > @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) > > Description from the original issue: >> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >> >> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >> >> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. > > Testing: Tier 1-7 Axel Boldt-Christmas 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: - Fix for shenandoah - Merge remote-tracking branch 'upstream/master' into JDK-8291718 - Extend CodeCache::UnloadingScope to include klass unloading - Remove double counting _perf_total_buckets_deallocated_count - Fix indentation - Revert "Simplify and assert in remove_all_dependents" This reverts commit 0141b28d3b30745da31e12a4489ac71e14bd18e2. - Fix indentation - Simplify and assert in remove_all_dependents - 8291718: Remove mark_for_deoptimization from klass unloading ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9713/files - new: https://git.openjdk.org/jdk/pull/9713/files/019d4d1c..25f33908 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=05-06 Stats: 3345 lines in 202 files changed: 1904 ins; 1139 del; 302 mod Patch: https://git.openjdk.org/jdk/pull/9713.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9713/head:pull/9713 PR: https://git.openjdk.org/jdk/pull/9713 From jwaters at openjdk.org Mon Aug 8 18:02:18 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 18:02:18 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v12] In-Reply-To: References: Message-ID: > JLI_ReportErrorMessageSys has a number of issues, as listed below: > > - The windows variant prints message, then extra-info if available, but the Unix variant prints first extra-info, then message on a newline. Standardize both to print their system errors on newlines below the message. > > - The Windows implementation intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. There is no way for JLI_ReportErrorMessageSys to know which is the right code. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call. Changing JLI_ReportErrorMessageSys to add Windows specific components is not desired, so as a compromise we can simply print both Win32 and C Runtime errors together, if both exist. > > - On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice. > > - Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care of separation itself. > > Side note: The javaw implementation in this patch for Windows is a bit of a mess, advice or improvements to it are appreciated Julian Waters 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: Finalize Unix implementation, Windows to follow after ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9793/files - new: https://git.openjdk.org/jdk/pull/9793/files/c166e551..be7d0a9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9793&range=10-11 Stats: 8 lines in 1 file changed: 4 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9793.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9793/head:pull/9793 PR: https://git.openjdk.org/jdk/pull/9793 From sviswanathan at openjdk.org Mon Aug 8 18:30:17 2022 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 8 Aug 2022 18:30:17 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 16:36:23 GMT, Smita Kamath wrote: > 8289552: Make intrinsic conversions between bit representations of half precision values and floats src/hotspot/cpu/x86/assembler_x86.cpp line 1927: > 1925: assert(VM_Version::supports_evex(), ""); > 1926: InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ true, /*uses_vl */ true); > 1927: attributes.set_is_evex_instruction(); This instruction is supported on AVX (vex encoded) platform as well. Please rename this as vcvtps2ph and update the check to include supports_evex or supports_f16C. The is_evex_instruction check should then be remvoed. src/hotspot/cpu/x86/assembler_x86.cpp line 1931: > 1929: emit_int8((unsigned char)0x1D); > 1930: emit_int8((unsigned char)(0xC0 | encode)); > 1931: emit_int8(imm8); You could do emit_int24() here. src/hotspot/cpu/x86/assembler_x86.cpp line 1937: > 1935: assert(VM_Version::supports_evex(), ""); > 1936: InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */false, /* no_mask_reg */ true, /* uses_vl */ true); > 1937: attributes.set_is_evex_instruction(); This instruction is supported on AVX (vex encoded) platform as well. Please rename this as vcvtph2ps and update the check to include supports_evex or supports_f16C. The is_evex_instruction check should then be remvoed. src/hotspot/cpu/x86/x86.ad line 1686: > 1684: case Op_ConvHF2F: > 1685: if (!VM_Version::supports_evex() || !VM_Version::supports_avx512vl()) { > 1686: return false; Please include supports_f16c here. src/hotspot/cpu/x86/x86_64.ad line 11310: > 11308: > 11309: instruct convF2HF_reg_reg(rRegI dst, regF src, regF tmp) %{ > 11310: predicate(VM_Version::supports_evex()); The predicate could be removed as the check is fully done in match_rule_supported. src/hotspot/cpu/x86/x86_64.ad line 11313: > 11311: effect(TEMP tmp); > 11312: match(Set dst (ConvF2HF src)); > 11313: format %{ "evcvtps2ph $dst,$src" %} It will be good to also show the tmp register in the format. src/hotspot/cpu/x86/x86_64.ad line 11323: > 11321: > 11322: instruct convHF2F_reg_reg(regF dst, rRegI src) %{ > 11323: predicate(VM_Version::supports_evex()); The predicate could be removed as it is fully covered in the match_rule_supported. src/hotspot/share/opto/convertnode.cpp line 251: > 249: //------------------------------Identity--------------------------------------- > 250: Node* ConvHF2FNode::Identity(PhaseGVN* phase) { > 251: return (in(1)->Opcode() == Op_ConvF2HF) ? in(1)->in(1) : this; We cannot do this optimization: HF2F(F2HF(x)) != x This is because precision and range both are lost when we convert F2HF. src/hotspot/share/opto/convertnode.hpp line 150: > 148: virtual const Type *bottom_type() const { return Type::FLOAT; } > 149: virtual const Type* Value(PhaseGVN* phase) const; > 150: virtual Node* Identity(PhaseGVN* phase); The identity method could be removed from ConvHF2FNode ------------- PR: https://git.openjdk.org/jdk/pull/9781 From sviswanathan at openjdk.org Mon Aug 8 18:30:18 2022 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 8 Aug 2022 18:30:18 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 23:58:49 GMT, Joe Darcy wrote: >> @jddarcy Thanks for your comment. I am not sure if there is a way of using Java library implementation here. > > I was under the impression that if a platform didn't have special support for the functionality in question it could not have the intrinsic and just use the Java library implementation? @jddarcy This code is for constant expression evaluation during C2 compilation. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From duke at openjdk.org Mon Aug 8 19:19:58 2022 From: duke at openjdk.org (Yi-Fan Tsai) Date: Mon, 8 Aug 2022 19:19:58 GMT Subject: RFR: 8280152: AArch64: Reuse runtime call trampolines [v4] In-Reply-To: <2yzoo-9v59f9D8mZuYQp9qL-ufvo3-0T1aKuGA65YQ4=.e33d044f-5f60-464e-b6b4-b06496a59f11@github.com> References: <2Rz88X0uWMdi7N4NFC36ZiMXgOhUmh0XehnaOKo6JWM=.9422ee14-4e73-47a5-a211-842fa5331391@github.com> <2yzoo-9v59f9D8mZuYQp9qL-ufvo3-0T1aKuGA65YQ4=.e33d044f-5f60-464e-b6b4-b06496a59f11@github.com> Message-ID: On Fri, 22 Jul 2022 08:17:56 GMT, Andrew Haley wrote: >> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision: >> >> Use ResizeableResourceHashtable > > I'm still looking at this, but it seems rather eccentric to create an array of all the calls, then create a hash table from the array. @theRealAph @nick-arm May you review the change again? ------------- PR: https://git.openjdk.org/jdk/pull/9405 From iklam at openjdk.org Mon Aug 8 19:50:04 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 8 Aug 2022 19:50:04 GMT Subject: RFR: 8291970: Add TableStatistics get function to ResourceHashtable In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 14:47:39 GMT, Coleen Phillimore wrote: > Add a statistics_calculate function to ResourceHashtable so that we can use it for printing. Also add a test. > Tested with tier1 on Oracle platforms (with and without product build). Looks good. I think the test can be simplified by using `ResourceHashtable` so you don't need to explicitly delete the values. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/9775 From coleenp at openjdk.org Mon Aug 8 20:01:42 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 8 Aug 2022 20:01:42 GMT Subject: RFR: 8291970: Add TableStatistics get function to ResourceHashtable In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 14:47:39 GMT, Coleen Phillimore wrote: > Add a statistics_calculate function to ResourceHashtable so that we can use it for printing. Also add a test. > Tested with tier1 on Oracle platforms (with and without product build). I wanted to show the printer lambda getting the literal size of the value, so needed to make it a pointer. Thanks for reviewing. ------------- PR: https://git.openjdk.org/jdk/pull/9775 From dlong at openjdk.org Mon Aug 8 20:51:08 2022 From: dlong at openjdk.org (Dean Long) Date: Mon, 8 Aug 2022 20:51:08 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings If the nmethod shouldn't be on the marked list at certain state transitions, how about adding asserts that check this? Using the same "self looped" trick that the Sweeper removal PR uses might help with that. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From iklam at openjdk.org Mon Aug 8 21:50:17 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 8 Aug 2022 21:50:17 GMT Subject: RFR: 8291945: Add OSInfo API for static OS information [v2] In-Reply-To: References: Message-ID: > As suggested by @tstuefe in the review of #9600, many of the `os` APIs simply return a value that was initialized during VM start up. E.g., `os::vm_page_size()`. I have added a new class `OSInfo` for managing such info > > - Simplifies the per-OS implementation > - Make the "init-only-once" check consistent > - In some cases, the simpler `OSInfo` class can be used in lieu of the more complex `os` class. This improves HotSpot build time (e.g., relocInfo.hpp). > > Note: I moved only 2 fields in this PR as a first step. If this works well I plan to move more fields in the future. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9758/files - new: https://git.openjdk.org/jdk/pull/9758/files/9e918e8e..3da77fcb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9758&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9758&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9758.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9758/head:pull/9758 PR: https://git.openjdk.org/jdk/pull/9758 From iklam at openjdk.org Mon Aug 8 22:14:25 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 8 Aug 2022 22:14:25 GMT Subject: RFR: 8292007: Do not include vmSymbol.hpp in method.hpp Message-ID: A small build speed improvement: The popular header method.hpp has this inline function bool is_continuation_enter_intrinsic() const { return intrinsic_id() == vmIntrinsics::_Continuation_enterSpecial; } which causes the large header files vmSymbols.hpp and vmIntrinsics.hpp to be unnecessarily included by many HotSpot object files. The fix is to move this function to method.inline.hpp. (It might be performance critical since it's used by some loops that walk the call frames). ------------- Commit messages: - 8292007: Do not include vmSymbol.hpp in method.hpp Changes: https://git.openjdk.org/jdk/pull/9789/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9789&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292007 Stats: 25 lines in 13 files changed: 18 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9789.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9789/head:pull/9789 PR: https://git.openjdk.org/jdk/pull/9789 From ccheung at openjdk.org Mon Aug 8 23:26:18 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 8 Aug 2022 23:26:18 GMT Subject: RFR: 8291970: Add TableStatistics get function to ResourceHashtable In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 14:47:39 GMT, Coleen Phillimore wrote: > Add a statistics_calculate function to ResourceHashtable so that we can use it for printing. Also add a test. > Tested with tier1 on Oracle platforms (with and without product build). Looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/9775 From rsunderbabu at openjdk.org Tue Aug 9 03:14:27 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Tue, 9 Aug 2022 03:14:27 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v3] In-Reply-To: References: Message-ID: <-CVGoeiLEZWOmZr4BD2GamNGRf8lcUDGBO0BbywCakk=.079c5fa5-ddfe-4b20-aca9-feef3381ec58@github.com> > Tested with all GC options Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9658/files - new: https://git.openjdk.org/jdk/pull/9658/files/3d0e3948..24581de0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9658&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9658&range=01-02 Stats: 20 lines in 2 files changed: 9 ins; 4 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9658.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9658/head:pull/9658 PR: https://git.openjdk.org/jdk/pull/9658 From duke at openjdk.org Tue Aug 9 05:11:17 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Tue, 9 Aug 2022 05:11:17 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v7] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 17:31:31 GMT, Axel Boldt-Christmas wrote: >> @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) >> >> Description from the original issue: >>> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >>> >>> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >>> >>> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. >> >> Testing: Tier 1-7 > > Axel Boldt-Christmas 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: > > - Fix for shenandoah > - Merge remote-tracking branch 'upstream/master' into JDK-8291718 > - Extend CodeCache::UnloadingScope to include klass unloading > - Remove double counting _perf_total_buckets_deallocated_count > - Fix indentation > - Revert "Simplify and assert in remove_all_dependents" > > This reverts commit 0141b28d3b30745da31e12a4489ac71e14bd18e2. > - Fix indentation > - Simplify and assert in remove_all_dependents > - 8291718: Remove mark_for_deoptimization from klass unloading Tier 1-7 testing done. ------------- PR: https://git.openjdk.org/jdk/pull/9713 From duke at openjdk.org Tue Aug 9 05:17:14 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Tue, 9 Aug 2022 05:17:14 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v8] In-Reply-To: References: Message-ID: <3Bei4QWe3XF1aS0bNKuHAXWkLTfXBf-Ug8OjzPPDEnw=.ce2e8c62-2313-47c0-84ca-fc456d0d2da8@github.com> > @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) > > Description from the original issue: >> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >> >> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >> >> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. > > Testing: Tier 1-7 Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Remove indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9713/files - new: https://git.openjdk.org/jdk/pull/9713/files/25f33908..f6dcef08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9713&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9713.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9713/head:pull/9713 PR: https://git.openjdk.org/jdk/pull/9713 From eosterlund at openjdk.org Tue Aug 9 06:10:22 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 9 Aug 2022 06:10:22 GMT Subject: RFR: 8290025: Remove the Sweeper [v8] In-Reply-To: References: Message-ID: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Redundant variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9741/files - new: https://git.openjdk.org/jdk/pull/9741/files/07470c52..3cd50998 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=06-07 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9741/head:pull/9741 PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Tue Aug 9 06:10:25 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 9 Aug 2022 06:10:25 GMT Subject: RFR: 8290025: Remove the Sweeper [v3] In-Reply-To: References: Message-ID: <-QWxth_jMerNMI745-IXaEwYYSPtbfwQwR3Lk5lV8mg=.5010da30-f7c2-4d5b-9f51-378cfa457532@github.com> On Fri, 5 Aug 2022 04:10:09 GMT, David Schlosnagle wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback v2 > > src/hotspot/share/code/codeCache.cpp line 714: > >> 712: size_t max = max_capacity(); >> 713: size_t used = max - free; >> 714: double gc_interval = time - last_time; > > Are `gc_interval` and `duration` both needed? They seem duplicative. Fixed. Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From rsunderbabu at openjdk.org Tue Aug 9 07:33:22 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Tue, 9 Aug 2022 07:33:22 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v4] In-Reply-To: References: Message-ID: > Tested with all GC options Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9658/files - new: https://git.openjdk.org/jdk/pull/9658/files/24581de0..0c6c8675 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9658&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9658&range=02-03 Stats: 15 lines in 1 file changed: 8 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9658.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9658/head:pull/9658 PR: https://git.openjdk.org/jdk/pull/9658 From eosterlund at openjdk.org Tue Aug 9 09:45:20 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 9 Aug 2022 09:45:20 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v8] In-Reply-To: <3Bei4QWe3XF1aS0bNKuHAXWkLTfXBf-Ug8OjzPPDEnw=.ce2e8c62-2313-47c0-84ca-fc456d0d2da8@github.com> References: <3Bei4QWe3XF1aS0bNKuHAXWkLTfXBf-Ug8OjzPPDEnw=.ce2e8c62-2313-47c0-84ca-fc456d0d2da8@github.com> Message-ID: <8MP5MDAmRDNQuBAqSqblozGJKfjAH2fUj_qRVootk-0=.222848db-11fe-4624-9738-914b902f0509@github.com> On Tue, 9 Aug 2022 05:17:14 GMT, Axel Boldt-Christmas wrote: >> @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) >> >> Description from the original issue: >>> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >>> >>> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >>> >>> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. >> >> Testing: Tier 1-7 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Remove indentation Marked as reviewed by eosterlund (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9713 From coleenp at openjdk.org Tue Aug 9 12:01:34 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 9 Aug 2022 12:01:34 GMT Subject: RFR: 8291970: Add TableStatistics get function to ResourceHashtable In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 14:47:39 GMT, Coleen Phillimore wrote: > Add a statistics_calculate function to ResourceHashtable so that we can use it for printing. Also add a test. > Tested with tier1 on Oracle platforms (with and without product build). Thanks Calvin! ------------- PR: https://git.openjdk.org/jdk/pull/9775 From coleenp at openjdk.org Tue Aug 9 12:01:35 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 9 Aug 2022 12:01:35 GMT Subject: Integrated: 8291970: Add TableStatistics get function to ResourceHashtable In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 14:47:39 GMT, Coleen Phillimore wrote: > Add a statistics_calculate function to ResourceHashtable so that we can use it for printing. Also add a test. > Tested with tier1 on Oracle platforms (with and without product build). This pull request has now been integrated. Changeset: f5b3618c Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/f5b3618c421904a99d1754c10344e92459eeb4ad Stats: 74 lines in 4 files changed: 71 ins; 0 del; 3 mod 8291970: Add TableStatistics get function to ResourceHashtable Reviewed-by: iklam, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/9775 From coleenp at openjdk.org Tue Aug 9 12:36:00 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 9 Aug 2022 12:36:00 GMT Subject: RFR: 8292068: Convert ModuleEntryTable into ResourceHashtable Message-ID: Converted the ModuleEntryTable to use ResourceHashtable. Ran tiers 1-7. Also ran performance tests with this and other changes with no performance difference, although the footprint of this should be better. ------------- Commit messages: - 8292068: Convert ModuleEntryTable into ResourceHashtable Changes: https://git.openjdk.org/jdk/pull/9809/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9809&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292068 Stats: 366 lines in 8 files changed: 108 ins; 182 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/9809.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9809/head:pull/9809 PR: https://git.openjdk.org/jdk/pull/9809 From coleenp at openjdk.org Tue Aug 9 12:39:18 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 9 Aug 2022 12:39:18 GMT Subject: RFR: 8292007: Do not include vmSymbol.hpp in method.hpp In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 02:04:42 GMT, Ioi Lam wrote: > A small build speed improvement: > > The popular header method.hpp has this inline function > > > bool is_continuation_enter_intrinsic() const { > return intrinsic_id() == vmIntrinsics::_Continuation_enterSpecial; > } > > > which causes the large header files vmSymbols.hpp and vmIntrinsics.hpp to be unnecessarily included by many HotSpot object files. > > The fix is to move this function to method.inline.hpp. > > (It might be performance critical since it's used by some loops that walk the call frames). Looks good. GHA likes it so it can be deemed trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/9789 From shade at openjdk.org Tue Aug 9 18:11:37 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 9 Aug 2022 18:11:37 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null [v2] In-Reply-To: References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: <1Tqhx9xFVxs-l-rJgclykRTouDLC6GjJAjHz14F3l7k=.634f2fdd-97da-41f0-8544-a501c4a52883@github.com> On Wed, 3 Aug 2022 18:39:19 GMT, Aleksey Shipilev wrote: >> These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL: >> >> >> static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS) >> NOT_MANAGEMENT_RETURN_(NULL); >> ``` >> >> I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0 >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier1` >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier2` >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Cleaner fix Ping? I would like to push it soon. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9718 From iklam at openjdk.org Tue Aug 9 20:11:11 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Aug 2022 20:11:11 GMT Subject: RFR: 8292007: Do not include vmSymbol.hpp in method.hpp [v2] In-Reply-To: References: Message-ID: <3IE8p4SYOZgGsGQXBrzxWTVWHpVF90yvW4kQdYfVag8=.217ef41c-154a-4001-9889-360b59932cf6@github.com> > A small build speed improvement: > > The popular header method.hpp has this inline function > > > bool is_continuation_enter_intrinsic() const { > return intrinsic_id() == vmIntrinsics::_Continuation_enterSpecial; > } > > > which causes the large header files vmSymbols.hpp and vmIntrinsics.hpp to be unnecessarily included by many HotSpot object files. > > The fix is to move this function to method.inline.hpp. > > (It might be performance critical since it's used by some loops that walk the call frames). 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' of https://github.com/openjdk/jdk into 8292007-dont-include-vmSymbol-in-method-hpp - 8292007: Do not include vmSymbol.hpp in method.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9789/files - new: https://git.openjdk.org/jdk/pull/9789/files/65363ee9..ef6fd477 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9789&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9789&range=00-01 Stats: 2460 lines in 105 files changed: 1652 ins; 520 del; 288 mod Patch: https://git.openjdk.org/jdk/pull/9789.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9789/head:pull/9789 PR: https://git.openjdk.org/jdk/pull/9789 From duke at openjdk.org Tue Aug 9 20:24:33 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 9 Aug 2022 20:24:33 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call [v2] In-Reply-To: References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: On Fri, 5 Aug 2022 20:22:17 GMT, Vladimir Kozlov wrote: >> Evgeny Astigeevich has updated the pull request incrementally with three additional commits since the last revision: >> >> - Restore original NativeCall::trampoline_jump functionality >> - Substitute entry.target() with target >> - Remove unneeded assert > > Good. @vnkozlov @theRealAph, any comments on the version with the virtual `in_scratch_emit_size()`? ------------- PR: https://git.openjdk.org/jdk/pull/9782 From lmesnik at openjdk.org Tue Aug 9 21:09:38 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 9 Aug 2022 21:09:38 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v3] In-Reply-To: <-CVGoeiLEZWOmZr4BD2GamNGRf8lcUDGBO0BbywCakk=.079c5fa5-ddfe-4b20-aca9-feef3381ec58@github.com> References: <-CVGoeiLEZWOmZr4BD2GamNGRf8lcUDGBO0BbywCakk=.079c5fa5-ddfe-4b20-aca9-feef3381ec58@github.com> Message-ID: On Tue, 9 Aug 2022 03:14:27 GMT, Ramkumar Sunderbabu wrote: >> Tested with all GC options > > Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: > > 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java line 99: > 97: > 98: while (++iteration < YOUNG_GC_ITERATIONS) { > 99: byteArrayProducer.create(memChunk); please add these object to array like initialAlloc to have objects of various ages in different heap gens ------------- PR: https://git.openjdk.org/jdk/pull/9658 From lmesnik at openjdk.org Tue Aug 9 21:09:36 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 9 Aug 2022 21:09:36 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v4] In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 07:33:22 GMT, Ramkumar Sunderbabu wrote: >> Tested with all GC options > > Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: > > 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" Marked as reviewed by lmesnik (Reviewer). test/hotspot/jtreg/vmTestbase/gc/lock/LockerTest.java line 54: > 52: ExecutionController stresser = getExecutionController(); > 53: // Use only 30% of the heap. > 54: final long testMemory = 3 * Runtime.getRuntime().maxMemory() / 10; might be better to rename to testMemorySize ------------- PR: https://git.openjdk.org/jdk/pull/9658 From rsunderbabu at openjdk.org Wed Aug 10 00:15:49 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Wed, 10 Aug 2022 00:15:49 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v4] In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 21:05:32 GMT, Leonid Mesnik wrote: >> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: >> >> 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" > > test/hotspot/jtreg/vmTestbase/gc/lock/LockerTest.java line 54: > >> 52: ExecutionController stresser = getExecutionController(); >> 53: // Use only 30% of the heap. >> 54: final long testMemory = 3 * Runtime.getRuntime().maxMemory() / 10; > > might be better to rename to testMemorySize I prefer to leave it as engageGC, it shows the intent better. ------------- PR: https://git.openjdk.org/jdk/pull/9658 From lmesnik at openjdk.org Wed Aug 10 00:26:32 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 10 Aug 2022 00:26:32 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v4] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 00:13:18 GMT, Ramkumar Sunderbabu wrote: >> test/hotspot/jtreg/vmTestbase/gc/lock/LockerTest.java line 54: >> >>> 52: ExecutionController stresser = getExecutionController(); >>> 53: // Use only 30% of the heap. >>> 54: final long testMemory = 3 * Runtime.getRuntime().maxMemory() / 10; >> >> might be better to rename to testMemorySize > > I prefer to leave it as engageGC, it shows the intent better. I meant rename testMemory to testMemorySize ------------- PR: https://git.openjdk.org/jdk/pull/9658 From vlivanov at openjdk.org Wed Aug 10 00:55:16 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 10 Aug 2022 00:55:16 GMT Subject: RFR: 8292153: x86: Represent Registers as values Message-ID: As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads. Proposed change hides pointer representation behind value class. Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). Code quality doesn't suffer (and even slightly improves): https://godbolt.org/z/d8dGM1eY1 (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) Testing: hs-tier1 - hs-tier5 PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. ------------- Commit messages: - x86: Register class wrappers Changes: https://git.openjdk.org/jdk/pull/9815/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9815&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292153 Stats: 557 lines in 28 files changed: 153 ins; 89 del; 315 mod Patch: https://git.openjdk.org/jdk/pull/9815.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9815/head:pull/9815 PR: https://git.openjdk.org/jdk/pull/9815 From rsunderbabu at openjdk.org Wed Aug 10 02:11:35 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Wed, 10 Aug 2022 02:11:35 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v4] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 00:24:25 GMT, Leonid Mesnik wrote: >> I prefer to leave it as engageGC, it shows the intent better. > > I meant rename testMemory to testMemorySize Oh! I misunderstood. Will submit changes. ------------- PR: https://git.openjdk.org/jdk/pull/9658 From rsunderbabu at openjdk.org Wed Aug 10 02:13:59 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Wed, 10 Aug 2022 02:13:59 GMT Subject: RFR: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" [v5] In-Reply-To: References: Message-ID: > Tested with all GC options Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9658/files - new: https://git.openjdk.org/jdk/pull/9658/files/0c6c8675..f9b0c370 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9658&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9658&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9658.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9658/head:pull/9658 PR: https://git.openjdk.org/jdk/pull/9658 From iklam at openjdk.org Wed Aug 10 03:00:39 2022 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Aug 2022 03:00:39 GMT Subject: RFR: 8292007: Do not include vmSymbol.hpp in method.hpp [v2] In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 12:35:26 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' of https://github.com/openjdk/jdk into 8292007-dont-include-vmSymbol-in-method-hpp >> - 8292007: Do not include vmSymbol.hpp in method.hpp > > Looks good. GHA likes it so it can be deemed trivial. Thanks to @coleenp for the review. Also passed build tiers 1 and 5 ------------- PR: https://git.openjdk.org/jdk/pull/9789 From iklam at openjdk.org Wed Aug 10 03:02:39 2022 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Aug 2022 03:02:39 GMT Subject: Integrated: 8292007: Do not include vmSymbol.hpp in method.hpp In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 02:04:42 GMT, Ioi Lam wrote: > A small build speed improvement: > > The popular header method.hpp has this inline function > > > bool is_continuation_enter_intrinsic() const { > return intrinsic_id() == vmIntrinsics::_Continuation_enterSpecial; > } > > > which causes the large header files vmSymbols.hpp and vmIntrinsics.hpp to be unnecessarily included by many HotSpot object files. > > The fix is to move this function to method.inline.hpp. > > (It might be performance critical since it's used by some loops that walk the call frames). This pull request has now been integrated. Changeset: 49133809 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/49133809c2331a8a2067228adceb1d6e97cb19a8 Stats: 25 lines in 13 files changed: 18 ins; 2 del; 5 mod 8292007: Do not include vmSymbol.hpp in method.hpp Reviewed-by: coleenp ------------- PR: https://git.openjdk.org/jdk/pull/9789 From stuefe at openjdk.org Wed Aug 10 04:58:36 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 10 Aug 2022 04:58:36 GMT Subject: RFR: 8292007: Do not include vmSymbol.hpp in method.hpp [v2] In-Reply-To: <3IE8p4SYOZgGsGQXBrzxWTVWHpVF90yvW4kQdYfVag8=.217ef41c-154a-4001-9889-360b59932cf6@github.com> References: <3IE8p4SYOZgGsGQXBrzxWTVWHpVF90yvW4kQdYfVag8=.217ef41c-154a-4001-9889-360b59932cf6@github.com> Message-ID: On Tue, 9 Aug 2022 20:11:11 GMT, Ioi Lam wrote: >> A small build speed improvement: >> >> The popular header method.hpp has this inline function >> >> >> bool is_continuation_enter_intrinsic() const { >> return intrinsic_id() == vmIntrinsics::_Continuation_enterSpecial; >> } >> >> >> which causes the large header files vmSymbols.hpp and vmIntrinsics.hpp to be unnecessarily included by many HotSpot object files. >> >> The fix is to move this function to method.inline.hpp. >> >> (It might be performance critical since it's used by some loops that walk the call frames). > > 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' of https://github.com/openjdk/jdk into 8292007-dont-include-vmSymbol-in-method-hpp > - 8292007: Do not include vmSymbol.hpp in method.hpp All good. ------------- PR: https://git.openjdk.org/jdk/pull/9789 From iklam at openjdk.org Wed Aug 10 06:05:37 2022 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Aug 2022 06:05:37 GMT Subject: RFR: 8292068: Convert ModuleEntryTable into ResourceHashtable In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 12:27:46 GMT, Coleen Phillimore wrote: > Converted the ModuleEntryTable to use ResourceHashtable. > Ran tiers 1-7. Also ran performance tests with this and other changes with no performance difference, although the footprint of this should be better. Changes requested by iklam (Reviewer). src/hotspot/share/classfile/moduleEntry.cpp line 287: > 285: } > 286: > 287: Symbol::maybe_increment_refcount(_version); Use set_version() instead, to be consistent with set_location() below. src/hotspot/share/classfile/moduleEntry.cpp line 359: > 357: public: > 358: bool do_entry(const Symbol*& name, ModuleEntry*& entry) { > 359: ResourceMark rm; The ResourceMark should be used inside `log_is_enabled(...) ` src/hotspot/share/classfile/moduleEntry.cpp line 595: > 593: // lookup_only by Symbol* to find a ModuleEntry. > 594: ModuleEntry* ModuleEntryTable::lookup_only(Symbol* name) { > 595: assert_locked_or_safepoint(Module_lock); Is it true that all public functions in the ModuleEntryTable class require the Module_lock to be held? If so, maybe this should be documented in the class declaration, and the assert to be added to all the functions. src/hotspot/share/classfile/moduleEntry.cpp line 681: > 679: > 680: void ModuleEntryTable::modules_do(void f(ModuleEntry*)) { > 681: auto do_f = [&] (const Symbol*& key, ModuleEntry*& entry) { assert locked? src/hotspot/share/classfile/moduleEntry.cpp line 688: > 686: > 687: void ModuleEntryTable::modules_do(ModuleClosure* closure) { > 688: auto do_f = [&] (const Symbol*& key, ModuleEntry*& entry) { assert locked? src/hotspot/share/classfile/moduleEntry.hpp line 209: > 207: static ModuleEntry* _javabase_module; > 208: ResourceHashtable 209: Symbol::compute_hash, Symbol::compare> _table; Is the `Symbol::compare` necessary? The `_invoke_method_type_table` table in systemDictionary.hpp is able to use the default comparison method. ------------- PR: https://git.openjdk.org/jdk/pull/9809 From rpressler at openjdk.org Wed Aug 10 08:14:35 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Wed, 10 Aug 2022 08:14:35 GMT Subject: RFR: 8291972: Fix double copy of arguments when thawing two interpreted frames In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 14:41:56 GMT, Patricio Chilano Mateo wrote: > When thawing two consecutive interpreted frames the current code makes room in the stack and copies the callee arguments twice, once in the caller and once in the callee. This duplication could use more stack space than the calculation made in prepare_thaw() for the maximum stack space that will be needed during thaw. If that's the case then we will hit an assert that we are writing pass the allowed limit. > Today we don't see this issue though because the only case where we could thaw two interpreter frames is the first time after a freeze. The thawed frames are always Continuation.yield and Continuation.yield0 and the extra used space is only 3 words(yield0's three arguments) which will never exceed the calculation made in prepare_thaw(). > The issue can be made visible when changing the number of frames we thaw when hitting a return barrier from 1 to 2 and running test Continuation/Basic.java. > > This patch fixes this by adjusting the calculated size of the callee frame in new_stack_frame() so that we use the space for the arguments already allocated by the caller. > > Tested the patch by changing the number of thaw frames from 1 to 2 and running all tests in jdk/internal/vm/Continuation/ and jdk/java/lang/Thread/virtual. Also run tiers1-3 in mach5 and loom-tiers1-4. > > Thanks, > Patricio Looks fine to me. ------------- Marked as reviewed by rpressler (Committer). PR: https://git.openjdk.org/jdk/pull/9774 From eosterlund at openjdk.org Wed Aug 10 09:11:04 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 10 Aug 2022 09:11:04 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive Message-ID: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed. There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load. I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong. ------------- Commit messages: - 8292077: G1 nmethod entry barriers don't keep oops alive Changes: https://git.openjdk.org/jdk/pull/9817/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9817&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292077 Stats: 22 lines in 1 file changed: 16 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9817.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9817/head:pull/9817 PR: https://git.openjdk.org/jdk/pull/9817 From pli at openjdk.org Wed Aug 10 09:43:25 2022 From: pli at openjdk.org (Pengfei Li) Date: Wed, 10 Aug 2022 09:43:25 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN Message-ID: Recently, an igvn infinite loop issue was reported. Git bisection shows it appears after our JDK-8289996 patch. But after that patch is backed out, we find similar test still fails. We have attached a jtreg case to reproduce this issue. The ideal graph of the problematic method has a `MulINode` multiplying a `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` moves the constant input to the right hand side. And `Ideal()` function in its parent class `MulNode` has the similar logic. In some code paths, `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, `MulINode` and `MulNode` use different ways to check constant. One calls `type->singleton()` and the other calls `node->find_int_con(val)` which accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` can be evaluated to a constant, the two inputs of the `MulNode` will be swapped back and forth in `Ideal()` calls. It eventually causes the igvn infinite loop issue. This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` because it's enough to do this by calling `MulNode::Ideal()`. We also do some code cleanup in this patch as we have done in JDK-8289996. Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. ------------- Commit messages: - 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN Changes: https://git.openjdk.org/jdk/pull/9820/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9820&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291466 Stats: 95 lines in 3 files changed: 77 ins; 3 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/9820.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9820/head:pull/9820 PR: https://git.openjdk.org/jdk/pull/9820 From aph at openjdk.org Wed Aug 10 09:51:38 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 10 Aug 2022 09:51:38 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call [v3] In-Reply-To: References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: On Mon, 8 Aug 2022 15:25:55 GMT, Evgeny Astigeevich wrote: >> `MacroAssembler::trampoline_call` can skip generation of a trampoline stub if C2 phase output is in the checking emitted code size mode. If it is not C2 compilation, `trampoline_call` always generates a trampoline stub. >> >> `gen_continuation_enter` as a part of C2 compilation needed to disable the functionality above. Now `trampoline_call` has the `check_emit_size` which allows to disable the functionality completely. Its default value is `true` which means the functionality is enabled. >> >> There are problems: >> - C2 specific code which must be properly guarded if it is not C2 compilation. The code has the risk of undefined behaviour (UB). It is done with `is_c2_compile`. [JDK-8291654](https://bugs.openjdk.org/browse/JDK-8291654) is an example of changes caused UB. >> - The default value of `check_emit_size`. The current value `true` allows C1 to access the C2 specific code. Setting the default value to `false` will require to review and to update every existing use of `trampoline_call`. It will complicate uses of `trampoline_call`: each time a decision needs to be done - use or not use the default. >> >> Summary of changes: >> - Have a virtual `in_scratch_emit_size` returning `false` by default. It is privately overridden in `C2_MacroAssembler`. The overridden version returns `true` if C2 phase output is in the checking emitted code size mode. >> - `check_emit_size` is removed because it is not needed any more. >> >> Tested with fastdebug/release builds: >> - `gtest`: Passed. >> - `tier1`...`tier4`: Passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Add virtual in_scratch_emit_size instead of emit_trampoline_stub Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9782 From aph at openjdk.org Wed Aug 10 10:07:37 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 10 Aug 2022 10:07:37 GMT Subject: RFR: 8292153: x86: Represent Registers as values In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 23:25:27 GMT, Vladimir Ivanov wrote: > As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads. > > Proposed change hides pointer representation behind value class. > > Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). > > Code quality doesn't suffer (and even slightly improves): > https://godbolt.org/z/d8dGM1eY1 > > (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) > > Testing: hs-tier1 - hs-tier5 > > PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 3509: > 3507: const Register g = rsi; > 3508: const Register h = rdi; > 3509: const Register empty = noreg; // will never be used, in order not Shade and I were looking at this bug a week or so ago, but agreed to leave it because this patch would find and fix it. Good! ------------- PR: https://git.openjdk.org/jdk/pull/9815 From aph at openjdk.org Wed Aug 10 10:22:46 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 10 Aug 2022 10:22:46 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null [v2] In-Reply-To: References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: <1ti6FwScSqtigFI65N7U6zsH8CmpUyFwcfHi81GoeTI=.92943fc1-f85f-46cc-bbe2-6d18d8ff7a88@github.com> On Wed, 3 Aug 2022 18:39:19 GMT, Aleksey Shipilev wrote: >> These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL: >> >> >> static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS) >> NOT_MANAGEMENT_RETURN_(NULL); >> ``` >> >> I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0 >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier1` >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier2` >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Cleaner fix Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9718 From coleenp at openjdk.org Wed Aug 10 12:14:37 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Aug 2022 12:14:37 GMT Subject: RFR: 8292068: Convert ModuleEntryTable into ResourceHashtable In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 05:42:01 GMT, Ioi Lam wrote: >> Converted the ModuleEntryTable to use ResourceHashtable. >> Ran tiers 1-7. Also ran performance tests with this and other changes with no performance difference, although the footprint of this should be better. > > src/hotspot/share/classfile/moduleEntry.cpp line 287: > >> 285: } >> 286: >> 287: Symbol::maybe_increment_refcount(_version); > > Use set_version() instead, to be consistent with set_location() below. ok, I should have done that. ------------- PR: https://git.openjdk.org/jdk/pull/9809 From fjiang at openjdk.org Wed Aug 10 12:18:21 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 10 Aug 2022 12:18:21 GMT Subject: RFR: 8292187: aarch64: Remove duplicate header files Message-ID: It's a trivial patch that removes duplicate included header files under hotspot/cpu/aarch64. aarch64 release and fastdebug build with `--disable-precompiled-headers` passed. ------------- Commit messages: - Remove duplicate header files Changes: https://git.openjdk.org/jdk/pull/9821/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9821&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292187 Stats: 8 lines in 3 files changed: 1 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9821.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9821/head:pull/9821 PR: https://git.openjdk.org/jdk/pull/9821 From coleenp at openjdk.org Wed Aug 10 12:21:54 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Aug 2022 12:21:54 GMT Subject: RFR: 8292068: Convert ModuleEntryTable into ResourceHashtable In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 05:45:40 GMT, Ioi Lam wrote: >> Converted the ModuleEntryTable to use ResourceHashtable. >> Ran tiers 1-7. Also ran performance tests with this and other changes with no performance difference, although the footprint of this should be better. > > src/hotspot/share/classfile/moduleEntry.cpp line 359: > >> 357: public: >> 358: bool do_entry(const Symbol*& name, ModuleEntry*& entry) { >> 359: ResourceMark rm; > > The ResourceMark should be used inside `log_is_enabled(...) ` this usage is ugly but I'll add it because of the as_C_string() is used only if logging. > src/hotspot/share/classfile/moduleEntry.cpp line 595: > >> 593: // lookup_only by Symbol* to find a ModuleEntry. >> 594: ModuleEntry* ModuleEntryTable::lookup_only(Symbol* name) { >> 595: assert_locked_or_safepoint(Module_lock); > > Is it true that all public functions in the ModuleEntryTable class require the Module_lock to be held? If so, maybe this should be documented in the class declaration, and the assert to be added to all the functions. It is true, but wasn't true when the ModuleTable first was developed. I'll add the asserts. > src/hotspot/share/classfile/moduleEntry.hpp line 209: > >> 207: static ModuleEntry* _javabase_module; >> 208: ResourceHashtable> 209: Symbol::compute_hash, Symbol::compare> _table; > > Is the `Symbol::compare` necessary? The `_invoke_method_type_table` table in systemDictionary.hpp is able to use the default comparison method. It is not necessary. ------------- PR: https://git.openjdk.org/jdk/pull/9809 From coleenp at openjdk.org Wed Aug 10 12:49:31 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Aug 2022 12:49:31 GMT Subject: RFR: 8292068: Convert ModuleEntryTable into ResourceHashtable In-Reply-To: References: Message-ID: <37BcMu2Ya1E3sot_t1OYjCwYgoC2A1SSOEeI2H3ziMI=.f39c0677-a3db-4fa1-b894-5b4c77ad3aa0@github.com> On Wed, 10 Aug 2022 12:15:56 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/moduleEntry.cpp line 595: >> >>> 593: // lookup_only by Symbol* to find a ModuleEntry. >>> 594: ModuleEntry* ModuleEntryTable::lookup_only(Symbol* name) { >>> 595: assert_locked_or_safepoint(Module_lock); >> >> Is it true that all public functions in the ModuleEntryTable class require the Module_lock to be held? If so, maybe this should be documented in the class declaration, and the assert to be added to all the functions. > > It is true, but wasn't true when the ModuleTable first was developed. I'll add the asserts. As suspected, there are places where we should have added taking the Module_lock. ------------- PR: https://git.openjdk.org/jdk/pull/9809 From duke at openjdk.org Wed Aug 10 12:53:14 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Wed, 10 Aug 2022 12:53:14 GMT Subject: RFR: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call [v2] In-Reply-To: References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: <9Wfftbnsuhj9pEw9O_4Sv6TOnfpxPiVoeqLAxWIpeLQ=.c6557a56-12e9-402d-b809-8ff85f27212a@github.com> On Mon, 8 Aug 2022 10:37:32 GMT, Andrew Haley wrote: >> This looks very wrong to me. We could usefully add trampolines to C1, and this just makes doing that more difficult. >> >> Why don't you just define is_c2_compilation() appropriately in macroAssembler? > >> Why don't you just define is_c2_compilation() appropriately in macroAssembler? > > Or (better) `in_scratch_emit_size()`? That's the semantics we want. @theRealAph Thank you ------------- PR: https://git.openjdk.org/jdk/pull/9782 From coleenp at openjdk.org Wed Aug 10 13:16:03 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Aug 2022 13:16:03 GMT Subject: RFR: 8292068: Convert ModuleEntryTable into ResourceHashtable [v2] In-Reply-To: References: Message-ID: > Converted the ModuleEntryTable to use ResourceHashtable. > Ran tiers 1-7. Also ran performance tests with this and other changes with no performance difference, although the footprint of this should be better. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Ioi's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9809/files - new: https://git.openjdk.org/jdk/pull/9809/files/b4444ab9..d8fc83e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9809&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9809&range=00-01 Stats: 19 lines in 4 files changed: 7 ins; 4 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9809.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9809/head:pull/9809 PR: https://git.openjdk.org/jdk/pull/9809 From coleenp at openjdk.org Wed Aug 10 13:16:03 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Aug 2022 13:16:03 GMT Subject: RFR: 8292068: Convert ModuleEntryTable into ResourceHashtable In-Reply-To: References: Message-ID: <6mW9ThEwi2xxIOWe5wgzhmgvZkJD2SSEX7RTZlg9gaA=.0fd48afd-34b6-4af0-8a88-d5e34adc85d0@github.com> On Tue, 9 Aug 2022 12:27:46 GMT, Coleen Phillimore wrote: > Converted the ModuleEntryTable to use ResourceHashtable. > Ran tiers 1-7. Also ran performance tests with this and other changes with no performance difference, although the footprint of this should be better. Thanks Ioi for reviewing this! I fixed the code for your comments and am rerunning tier1-3 in case of other missing Module_locks. I already ran jfr tests since there are places where jfr iterates through modules. ------------- PR: https://git.openjdk.org/jdk/pull/9809 From shade at openjdk.org Wed Aug 10 13:27:37 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 10 Aug 2022 13:27:37 GMT Subject: RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null [v2] In-Reply-To: References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: On Wed, 3 Aug 2022 18:39:19 GMT, Aleksey Shipilev wrote: >> These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL: >> >> >> static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS) >> NOT_MANAGEMENT_RETURN_(NULL); >> ``` >> >> I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0 >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier1` >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier2` >> - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Cleaner fix Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/9718 From shade at openjdk.org Wed Aug 10 13:30:14 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 10 Aug 2022 13:30:14 GMT Subject: Integrated: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null In-Reply-To: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> References: <8520iqyNFiBMrguemOlXfqy8pheleKgwwT7xIZviS98=.4ad4fa9e-fac9-4b3b-85b8-5cb48d810e06@github.com> Message-ID: On Tue, 2 Aug 2022 18:11:33 GMT, Aleksey Shipilev wrote: > These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL: > > > static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS) > NOT_MANAGEMENT_RETURN_(NULL); > ``` > > I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses. > > Additional testing: > - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0 > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier1` > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `tier2` > - [x] Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability` This pull request has now been integrated. Changeset: 37d3146c Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/37d3146cca2c40dd53fcebd9cb78595f018b3489 Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null Reviewed-by: dholmes, aph ------------- PR: https://git.openjdk.org/jdk/pull/9718 From tschatzl at openjdk.org Wed Aug 10 14:06:09 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Aug 2022 14:06:09 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive In-Reply-To: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: On Wed, 10 Aug 2022 09:01:59 GMT, Erik ?sterlund wrote: > The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed. > > There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load. > I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong. Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 44: > 42: > 43: class OopKeepaliveClosure : public OopClosure { > 44: private: Suggestion: This line can be dropped. src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 124: > 122: // seriously wrong. > 123: ++_current_phase; > 124: if (_current_phase == INT_MAX) { I would really prefer to deal with this in a separate issue. It does not have anything to do with keeping oops alive in the nmethod barrier. ------------- PR: https://git.openjdk.org/jdk/pull/9817 From aph at openjdk.org Wed Aug 10 14:08:48 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 10 Aug 2022 14:08:48 GMT Subject: RFR: 8292187: aarch64: Remove duplicate header files In-Reply-To: References: Message-ID: <8ED_Cc933lakBkbmfOfdSLvL2cRQl4AvKLr8Ahjeo3c=.15503b87-e37a-421a-ae62-d0ac00458684@github.com> On Wed, 10 Aug 2022 12:10:02 GMT, Feilong Jiang wrote: > It's a trivial patch that removes duplicate included header files under hotspot/cpu/aarch64. > > aarch64 release and fastdebug build with `--disable-precompiled-headers` passed. Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9821 From eosterlund at openjdk.org Wed Aug 10 14:17:23 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 10 Aug 2022 14:17:23 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v2] In-Reply-To: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: > The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed. > > There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load. > I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Thomas comments v1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9817/files - new: https://git.openjdk.org/jdk/pull/9817/files/1228e81c..b444499b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9817&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9817&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9817.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9817/head:pull/9817 PR: https://git.openjdk.org/jdk/pull/9817 From eosterlund at openjdk.org Wed Aug 10 14:31:35 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 10 Aug 2022 14:31:35 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v2] In-Reply-To: References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: On Wed, 10 Aug 2022 14:03:40 GMT, Thomas Schatzl wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas comments v1 > > Changes requested by tschatzl (Reviewer). Thanks for the review, @tschatzl . I applied your requested changes. ------------- PR: https://git.openjdk.org/jdk/pull/9817 From tschatzl at openjdk.org Wed Aug 10 14:38:52 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Aug 2022 14:38:52 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v2] In-Reply-To: References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: On Wed, 10 Aug 2022 14:17:23 GMT, Erik ?sterlund wrote: >> The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed. >> >> There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load. >> I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Thomas comments v1 Ship it ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9817 From stefank at openjdk.org Wed Aug 10 14:38:52 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 10 Aug 2022 14:38:52 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v2] In-Reply-To: References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: On Wed, 10 Aug 2022 14:17:23 GMT, Erik ?sterlund wrote: >> The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed. >> >> There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load. >> I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Thomas comments v1 Changes requested by stefank (Reviewer). src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 56: > 54: > 55: virtual void do_oop(narrowOop* p) { ShouldNotReachHere(); } > 56: }; * Keepalive should probably be KeepAlive. (I realize that AS_NO_KEEPALIVE doesn't split the two words, but that one is the outlier in the HotSpot code base) * Seems unnecessary to cache the heap pointer * Could this class be moved into the BarrierSetNMethod scope. Or, alternatively give it a more descriptive name stating that this is for nmethods and/or native phantom loads? I'm thinking about future name collisions and ODR. * Could you add a comment stating why you do this dance with AS_NO_KEEPALIVE + keep_alive(oop) ------------- PR: https://git.openjdk.org/jdk/pull/9817 From eosterlund at openjdk.org Wed Aug 10 14:57:40 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 10 Aug 2022 14:57:40 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v3] In-Reply-To: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: > The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed. > > There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load. > I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Stefan comments v1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9817/files - new: https://git.openjdk.org/jdk/pull/9817/files/b444499b..7f2f347e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9817&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9817&range=01-02 Stats: 33 lines in 1 file changed: 17 ins; 15 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9817.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9817/head:pull/9817 PR: https://git.openjdk.org/jdk/pull/9817 From tschatzl at openjdk.org Wed Aug 10 14:57:41 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Aug 2022 14:57:41 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v3] In-Reply-To: References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: On Wed, 10 Aug 2022 14:54:17 GMT, Erik ?sterlund wrote: >> The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed. >> >> There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load. >> I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Stefan comments v1 Still good. src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 66: > 64: class OopKeepAliveClosure : public OopClosure { > 65: public: > 66: OopKeepAliveClosure() {} The constructor could be removed as well now. Still looks good. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9817 From eosterlund at openjdk.org Wed Aug 10 14:57:43 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 10 Aug 2022 14:57:43 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v2] In-Reply-To: References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: <889TlTEonslxxXZCGarVGk-kJrPtgY3PX0vFOL3GKtA=.a2deccdd-3f53-4a75-af9d-02207ed56e73@github.com> On Wed, 10 Aug 2022 14:36:05 GMT, Thomas Schatzl wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas comments v1 > > Ship it Thanks for the review, @tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/9817 From eosterlund at openjdk.org Wed Aug 10 14:57:45 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 10 Aug 2022 14:57:45 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v2] In-Reply-To: References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: On Wed, 10 Aug 2022 14:36:24 GMT, Stefan Karlsson wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas comments v1 > > Changes requested by stefank (Reviewer). Thanks for the review, @stefank. I applied your requested changes. ------------- PR: https://git.openjdk.org/jdk/pull/9817 From duke at openjdk.org Wed Aug 10 15:00:47 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Wed, 10 Aug 2022 15:00:47 GMT Subject: Integrated: 8291752: AArch64: Remove check_emit_size parameter from trampoline_call In-Reply-To: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> References: <-2I3dVcuW7UJpI-Tst9kblG0qGyfCxZUxK7OgHuYlkQ=.402aa131-4acb-4d9a-a6fc-7d626a770eaa@github.com> Message-ID: On Fri, 5 Aug 2022 16:59:08 GMT, Evgeny Astigeevich wrote: > `MacroAssembler::trampoline_call` can skip generation of a trampoline stub if C2 phase output is in the checking emitted code size mode. If it is not C2 compilation, `trampoline_call` always generates a trampoline stub. > > `gen_continuation_enter` as a part of C2 compilation needed to disable the functionality above. Now `trampoline_call` has the `check_emit_size` which allows to disable the functionality completely. Its default value is `true` which means the functionality is enabled. > > There are problems: > - C2 specific code which must be properly guarded if it is not C2 compilation. The code has the risk of undefined behaviour (UB). It is done with `is_c2_compile`. [JDK-8291654](https://bugs.openjdk.org/browse/JDK-8291654) is an example of changes caused UB. > - The default value of `check_emit_size`. The current value `true` allows C1 to access the C2 specific code. Setting the default value to `false` will require to review and to update every existing use of `trampoline_call`. It will complicate uses of `trampoline_call`: each time a decision needs to be done - use or not use the default. > > Summary of changes: > - Have a virtual `in_scratch_emit_size` returning `false` by default. It is privately overridden in `C2_MacroAssembler`. The overridden version returns `true` if C2 phase output is in the checking emitted code size mode. > - `check_emit_size` is removed because it is not needed any more. > > Tested with fastdebug/release builds: > - `gtest`: Passed. > - `tier1`...`tier4`: Passed. This pull request has now been integrated. Changeset: cb37282a Author: Evgeny Astigeevich Committer: Volker Simonis URL: https://git.openjdk.org/jdk/commit/cb37282a12698ae66c27889db9251a5b278624b0 Stats: 48 lines in 5 files changed: 24 ins; 15 del; 9 mod 8291752: AArch64: Remove check_emit_size parameter from trampoline_call Reviewed-by: kvn, aph ------------- PR: https://git.openjdk.org/jdk/pull/9782 From eosterlund at openjdk.org Wed Aug 10 15:03:02 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 10 Aug 2022 15:03:02 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v4] In-Reply-To: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: <5SMHVnj3BcaRrOA77xnsydeHgxCpcsiQxk2mxQa2eKk=.7905a3de-6570-4966-a6d3-3b18c71f8646@github.com> > The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed. > > There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load. > I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Thomas comments v2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9817/files - new: https://git.openjdk.org/jdk/pull/9817/files/7f2f347e..b22387d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9817&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9817&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9817.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9817/head:pull/9817 PR: https://git.openjdk.org/jdk/pull/9817 From eosterlund at openjdk.org Wed Aug 10 15:03:05 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 10 Aug 2022 15:03:05 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v3] In-Reply-To: References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: On Wed, 10 Aug 2022 14:51:32 GMT, Thomas Schatzl wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Stefan comments v1 > > src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 66: > >> 64: class OopKeepAliveClosure : public OopClosure { >> 65: public: >> 66: OopKeepAliveClosure() {} > > The constructor could be removed as well now. Still looks good. Fixed. Thanks Thomas. ------------- PR: https://git.openjdk.org/jdk/pull/9817 From eosterlund at openjdk.org Wed Aug 10 15:12:22 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 10 Aug 2022 15:12:22 GMT Subject: RFR: 8292194: G1 nmethod entry barrier disarm value wraps around too early Message-ID: The disarm value for G1 nmethod entry barriers assumes that a concurrent GC can be aborted at most once. However, it can happen many times. In order to avoid ABA issues in the nmethod entry barriers, the limit for wrapping around and reusing numbers needs to be higher. This patch changes that point to INT_MAX as there is little point in using lower values. ------------- Commit messages: - 8292194: G1 nmethod entry barrier disarm value wraps around too early Changes: https://git.openjdk.org/jdk/pull/9822/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9822&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292194 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9822.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9822/head:pull/9822 PR: https://git.openjdk.org/jdk/pull/9822 From duke at openjdk.org Wed Aug 10 15:23:46 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Wed, 10 Aug 2022 15:23:46 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v3] In-Reply-To: References: Message-ID: <1duR3VoLYDa4MDvYCuEOmKf1IgrI_XAWIFeAoaxfYKE=.7aff1a6d-60c5-4777-8ddb-e21368a31cf8@github.com> > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. Axel Boldt-Christmas 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 20 additional commits since the last revision: - Initial draft new terminology - Make _context_active atomic - Missed merge changes - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Merge branch 'JDK-8291718' into JDK-8291237 - Remove indentation - Fix for shenandoah - Merge remote-tracking branch 'upstream/master' into JDK-8291718 - Extend CodeCache::UnloadingScope to include klass unloading - Remove double counting _perf_total_buckets_deallocated_count - ... and 10 more: https://git.openjdk.org/jdk/compare/f4067fb3...9f6f981d ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9655/files - new: https://git.openjdk.org/jdk/pull/9655/files/5d26ab8d..9f6f981d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=01-02 Stats: 15374 lines in 744 files changed: 8974 ins; 4345 del; 2055 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From duke at openjdk.org Wed Aug 10 15:52:44 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Wed, 10 Aug 2022 15:52:44 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v3] In-Reply-To: <1duR3VoLYDa4MDvYCuEOmKf1IgrI_XAWIFeAoaxfYKE=.7aff1a6d-60c5-4777-8ddb-e21368a31cf8@github.com> References: <1duR3VoLYDa4MDvYCuEOmKf1IgrI_XAWIFeAoaxfYKE=.7aff1a6d-60c5-4777-8ddb-e21368a31cf8@github.com> Message-ID: <1Ljfdir6k-NRJMOGOckyr92l-l7UULx-aBsX5GeDHDY=.31cb5b2e-174d-4daa-9d92-1da25cef36c1@github.com> On Wed, 10 Aug 2022 15:23:46 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas 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 20 additional commits since the last revision: > > - Initial draft new terminology > - Make _context_active atomic > - Missed merge changes > - Merge remote-tracking branch 'upstream/master' into JDK-8291237 > - Merge branch 'JDK-8291718' into JDK-8291237 > - Remove indentation > - Fix for shenandoah > - Merge remote-tracking branch 'upstream/master' into JDK-8291718 > - Extend CodeCache::UnloadingScope to include klass unloading > - Remove double counting _perf_total_buckets_deallocated_count > - ... and 10 more: https://git.openjdk.org/jdk/compare/443af4e1...9f6f981d Merged [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) into this as this change is dependent on that patch. Backed out the linked list enhancement. This is still a draft, and still need some work on the semantics of some enum statuses, and naming. Changed the terminology for deoptimization to stop using mark. Because the steps for deoptimization is always the following: 1. Create a list of nmethods to deoptimize (enqueueing) 2. Process the list 2.1. Make `nmethod` non entrant 2.2. (With continuations) patch `nmethod` `NativePostCallNop` instructions 3. Walk all frames and patch return pcs The mark_for was renamed enqueue, this makes it easier to talk about deoptimization in a context where marking is already a thing (e.g. GCs) and is more correct with regards to what the codes actually does. All remaining changes are with regards to `deoptimize_done` and that it does not really mean what it says. The comment in `update_recompile_counts()` describes the issue. The most correct thing would be to rename it to something like `deoptimize_post_call_installed` or `deoptimize_post_call_patched` and just leave it like that. No code currently cares if the deoptimization logic is completed (with regards to stack frame walking), only if an `nmethod` has enqueued deoptimization or not, and if `NativePostCallNop` instructions has been installed for loom. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From stefank at openjdk.org Wed Aug 10 16:03:46 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 10 Aug 2022 16:03:46 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v4] In-Reply-To: <5SMHVnj3BcaRrOA77xnsydeHgxCpcsiQxk2mxQa2eKk=.7905a3de-6570-4966-a6d3-3b18c71f8646@github.com> References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> <5SMHVnj3BcaRrOA77xnsydeHgxCpcsiQxk2mxQa2eKk=.7905a3de-6570-4966-a6d3-3b18c71f8646@github.com> Message-ID: On Wed, 10 Aug 2022 15:03:02 GMT, Erik ?sterlund wrote: >> The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed. >> >> There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load. >> I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Thomas comments v2 Thanks. Would you mind a few more tweaks? src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 67: > 65: public: > 66: virtual void do_oop(oop* p) { > 67: // Loads on nmethod oops are phantom strength. The intend of the load intend => intent? src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 71: > 69: // concurrent marking. Using the keep alive side effects of a normal > 70: // phantom load is less explicit, and doesn't actually do anything > 71: // unless the returned value is used as an oop. I think this is bit vague. Would it be OK if we explicitly spelled out the problem with the LoadOopProxy? Maybe something like this (feel free to tweak the actual text): // Loads on nmethod oops are phantom strength. // // Note: that we could have used NativeAccess::oop_load(p), // but that would have *required* us to convert the returned LoadOopProxy to an oop, // or else keep alive load barrier will never be called. It's the LoadOopProxy-to-oop // conversion that performs the load barriers. This is too subtle, so we instead // perform an explicit keep alive call. ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.org/jdk/pull/9817 From duke at openjdk.org Wed Aug 10 16:10:14 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Wed, 10 Aug 2022 16:10:14 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v4] In-Reply-To: References: Message-ID: > [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. > > This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. > > Testing: > - `tier1`...`tier4`: Passed > - `compiler/c2/aarch64/TestTrampoline.java`: Passed > > Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Add is_always_reachable(entry) - Merge branch 'master' into JDK-8285487 - Merge branch 'master' into JDK-8285487 - Merge branch 'master' into JDK-8285487 - Move code of target_needs_trampoline inside trampoline_call - XX:ReservedCodeCacheSize=130M for test and update comments - Remove debug code - 8285487: Do not generate trampolines for runtime calls if they are not needed ------------- Changes: https://git.openjdk.org/jdk/pull/8403/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8403&range=03 Stats: 161 lines in 2 files changed: 145 ins; 15 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/8403.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8403/head:pull/8403 PR: https://git.openjdk.org/jdk/pull/8403 From eosterlund at openjdk.org Wed Aug 10 16:51:26 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 10 Aug 2022 16:51:26 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v5] In-Reply-To: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: > The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed. > > There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load. > I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Stefan comments v2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9817/files - new: https://git.openjdk.org/jdk/pull/9817/files/b22387d0..e2038fa0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9817&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9817&range=03-04 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9817.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9817/head:pull/9817 PR: https://git.openjdk.org/jdk/pull/9817 From eosterlund at openjdk.org Wed Aug 10 16:51:29 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 10 Aug 2022 16:51:29 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v4] In-Reply-To: References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> <5SMHVnj3BcaRrOA77xnsydeHgxCpcsiQxk2mxQa2eKk=.7905a3de-6570-4966-a6d3-3b18c71f8646@github.com> Message-ID: On Wed, 10 Aug 2022 15:59:02 GMT, Stefan Karlsson wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas comments v2 > > src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 71: > >> 69: // concurrent marking. Using the keep alive side effects of a normal >> 70: // phantom load is less explicit, and doesn't actually do anything >> 71: // unless the returned value is used as an oop. > > I think this is bit vague. Would it be OK if we explicitly spelled out the problem with the LoadOopProxy? Maybe something like this (feel free to tweak the actual text): > > // Loads on nmethod oops are phantom strength. > // > // Note: that we could have used NativeAccess::oop_load(p), > // but that would have *required* us to convert the returned LoadOopProxy to an oop, > // or else keep alive load barrier will never be called. It's the LoadOopProxy-to-oop > // conversion that performs the load barriers. This is too subtle, so we instead > // perform an explicit keep alive call. I used your comment but removed the colon in "Note: that". Thanks for the review! ------------- PR: https://git.openjdk.org/jdk/pull/9817 From stefank at openjdk.org Wed Aug 10 16:56:41 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 10 Aug 2022 16:56:41 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v5] In-Reply-To: References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: On Wed, 10 Aug 2022 16:51:26 GMT, Erik ?sterlund wrote: >> The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed. >> >> There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load. >> I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Stefan comments v2 Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9817 From ngasson at openjdk.org Wed Aug 10 17:21:35 2022 From: ngasson at openjdk.org (Nick Gasson) Date: Wed, 10 Aug 2022 17:21:35 GMT Subject: RFR: 8292187: aarch64: Remove duplicate header files In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 12:10:02 GMT, Feilong Jiang wrote: > It's a trivial patch that removes duplicate included header files under hotspot/cpu/aarch64. > > aarch64 release and fastdebug build with `--disable-precompiled-headers` passed. Marked as reviewed by ngasson (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9821 From vlivanov at openjdk.org Wed Aug 10 17:22:34 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 10 Aug 2022 17:22:34 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v5] In-Reply-To: References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: On Wed, 10 Aug 2022 16:51:26 GMT, Erik ?sterlund wrote: >> The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed. >> >> There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load. >> I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Stefan comments v2 Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/9817 From eosterlund at openjdk.org Wed Aug 10 17:26:33 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 10 Aug 2022 17:26:33 GMT Subject: RFR: 8292077: G1 nmethod entry barriers don't keep oops alive [v5] In-Reply-To: References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: <9ykbYIoxIFkVhjGlcLv6-NBF72fARMw_GHZ-SQGn0Sw=.ea1cc6a3-a8da-4e75-ba05-86f725ef8eef@github.com> On Wed, 10 Aug 2022 17:19:00 GMT, Vladimir Ivanov wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Stefan comments v2 > > Looks good. Thanks for the reviews @iwanowww and @stefank! ------------- PR: https://git.openjdk.org/jdk/pull/9817 From vlivanov at openjdk.org Wed Aug 10 17:56:35 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 10 Aug 2022 17:56:35 GMT Subject: RFR: 8290025: Remove the Sweeper [v8] In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 06:10:22 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Redundant variable Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/9741 From lfoltan at openjdk.org Wed Aug 10 18:11:56 2022 From: lfoltan at openjdk.org (Lois Foltan) Date: Wed, 10 Aug 2022 18:11:56 GMT Subject: RFR: 8292068: Convert ModuleEntryTable into ResourceHashtable [v2] In-Reply-To: References: Message-ID: <8So1kZyYIIgKVVxSqJNGf28pUtQ3HvPlWjS7CVOhSaE=.4d88bd73-f507-477d-a3fd-9fe67bb8475f@github.com> On Wed, 10 Aug 2022 13:16:03 GMT, Coleen Phillimore wrote: >> Converted the ModuleEntryTable to use ResourceHashtable. >> Ran tiers 1-7. Also ran performance tests with this and other changes with no performance difference, although the footprint of this should be better. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Ioi's comments Looks good Coleen! Thanks, Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.org/jdk/pull/9809 From iklam at openjdk.org Wed Aug 10 18:15:34 2022 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Aug 2022 18:15:34 GMT Subject: RFR: 8292068: Convert ModuleEntryTable into ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 13:16:03 GMT, Coleen Phillimore wrote: >> Converted the ModuleEntryTable to use ResourceHashtable. >> Ran tiers 1-7. Also ran performance tests with this and other changes with no performance difference, although the footprint of this should be better. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Ioi's comments LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/9809 From coleenp at openjdk.org Wed Aug 10 18:25:42 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Aug 2022 18:25:42 GMT Subject: RFR: 8292068: Convert ModuleEntryTable into ResourceHashtable [v3] In-Reply-To: References: Message-ID: > Converted the ModuleEntryTable to use ResourceHashtable. > Ran tiers 1-7. Also ran performance tests with this and other changes with no performance difference, although the footprint of this should be better. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Revert modules_do() assert Module_lock and taking it for process_module_table. This should be fixed separately. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9809/files - new: https://git.openjdk.org/jdk/pull/9809/files/d8fc83e6..aed1a6da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9809&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9809&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9809.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9809/head:pull/9809 PR: https://git.openjdk.org/jdk/pull/9809 From coleenp at openjdk.org Wed Aug 10 18:29:35 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Aug 2022 18:29:35 GMT Subject: RFR: 8292068: Convert ModuleEntryTable into ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 13:16:03 GMT, Coleen Phillimore wrote: >> Converted the ModuleEntryTable to use ResourceHashtable. >> Ran tiers 1-7. Also ran performance tests with this and other changes with no performance difference, although the footprint of this should be better. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Ioi's comments I had to revert the modules_do asserts and locks because of JDK-8292202. ------------- PR: https://git.openjdk.org/jdk/pull/9809 From coleenp at openjdk.org Wed Aug 10 18:29:37 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Aug 2022 18:29:37 GMT Subject: RFR: 8292068: Convert ModuleEntryTable into ResourceHashtable [v3] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 18:25:42 GMT, Coleen Phillimore wrote: >> Converted the ModuleEntryTable to use ResourceHashtable. >> Ran tiers 1-7. Also ran performance tests with this and other changes with no performance difference, although the footprint of this should be better. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Revert modules_do() assert Module_lock and taking it for process_module_table. This should be fixed separately. Thanks Ioi and Lois. ------------- PR: https://git.openjdk.org/jdk/pull/9809 From eosterlund at openjdk.org Wed Aug 10 18:31:02 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 10 Aug 2022 18:31:02 GMT Subject: RFR: 8290025: Remove the Sweeper [v8] In-Reply-To: References: Message-ID: <0ATuMAd6EwVycE6YNcky9T43Qzy-IVcTNt5jH61Wy_4=.04e787c8-19cb-4f14-b133-e8a288641118@github.com> On Wed, 10 Aug 2022 17:54:26 GMT, Vladimir Ivanov wrote: > Looks good. Thanks for the review @iwanowww! ------------- PR: https://git.openjdk.org/jdk/pull/9741 From zgu at openjdk.org Wed Aug 10 19:27:43 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 10 Aug 2022 19:27:43 GMT Subject: RFR: 8290025: Remove the Sweeper [v8] In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 06:10:22 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Redundant variable src/hotspot/share/code/nmethod.hpp line 542: > 540: int64_t stack_traversal_mark() { return _stack_traversal_mark; } > 541: void set_stack_traversal_mark(int64_t l) { _stack_traversal_mark = l; } > 542: _stack_traversal_mark has no use now, can be deleted. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From zgu at openjdk.org Wed Aug 10 20:35:57 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 10 Aug 2022 20:35:57 GMT Subject: RFR: 8290025: Remove the Sweeper [v8] In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 06:10:22 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Redundant variable src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 482: > 480: GCCause::is_serviceability_requested_gc(cause) || > 481: cause == GCCause::_metadata_GC_clear_soft_refs || > 482: cause == GCCause::_codecache_GC_threshold || Please leave `_codecache_GC_threshold` cause here. Otherwise, it causes a few tests fail. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From vlivanov at openjdk.org Wed Aug 10 21:10:51 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 10 Aug 2022 21:10:51 GMT Subject: RFR: 8292153: x86: Represent Registers as values [v2] In-Reply-To: References: Message-ID: > As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads. > > Proposed change hides pointer representation behind value class. > > Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). > > Code quality doesn't suffer (and even slightly improves): > https://godbolt.org/z/d8dGM1eY1 > > (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) > > Testing: hs-tier1 - hs-tier5 > > PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: cleanups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9815/files - new: https://git.openjdk.org/jdk/pull/9815/files/4cb98cbd..478d4bed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9815&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9815&range=00-01 Stats: 33 lines in 2 files changed: 1 ins; 16 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/9815.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9815/head:pull/9815 PR: https://git.openjdk.org/jdk/pull/9815 From duke at openjdk.org Wed Aug 10 21:15:17 2022 From: duke at openjdk.org (AJ Ferguson) Date: Wed, 10 Aug 2022 21:15:17 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 Message-ID: Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. ------------- Commit messages: - exit preloop if len_reg is 0 Changes: https://git.openjdk.org/jdk/pull/9635/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9635&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292158 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9635.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9635/head:pull/9635 PR: https://git.openjdk.org/jdk/pull/9635 From duke at openjdk.org Wed Aug 10 21:18:11 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Wed, 10 Aug 2022 21:18:11 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v5] In-Reply-To: References: Message-ID: > [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. > > This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. > > Testing: > - `tier1`...`tier4`: Passed > - `compiler/c2/aarch64/TestTrampoline.java`: Passed > > Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Combine @requires; Change is_always_reachable to is_always_within_branch_range ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8403/files - new: https://git.openjdk.org/jdk/pull/8403/files/6ddc3f0a..4db9dfc9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8403&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8403&range=03-04 Stats: 9 lines in 2 files changed: 1 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/8403.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8403/head:pull/8403 PR: https://git.openjdk.org/jdk/pull/8403 From duke at openjdk.org Wed Aug 10 21:38:32 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Wed, 10 Aug 2022 21:38:32 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v5] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 21:18:11 GMT, Evgeny Astigeevich wrote: >> Runtime calls are calls of non-compiled methods. Non-compiled methods stay forever in CodeCache. If they are always within the branch range, they don't need trampolines. >> >> This PR adds `is_always_within_branch_range(Address entry)`. >> >> Results from DaCapo: the total number of eliminated trampolines per a benchmark run >> >> >> +----------+--------+ >> | avrora | 15491 | >> | batik | 75837 | >> | biojava | 13927 | >> | eclipse | 414143 | >> | fop | 119267 | >> | graphchi | 7665 | >> | jme | 8279 | >> | luindex | 56061 | >> | lusearch | 50277 | >> | pmd | 132719 | >> | sunflow | 10689 | >> | tomcat | 186967 | >> | xalan | 50349 | >> | zxing | 41497 | >> +----------+--------+ >> >> >> >> Testing: >> - `tier1`...`tier2`: Passed >> - `compiler/c2/aarch64/TestTrampoline.java`: Passed >> >> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Combine @requires; Change is_always_reachable to is_always_within_branch_range @theRealAph @navyxliu @vnkozlov @bulasevich I have updated the PR. Could you please have a look? ------------- PR: https://git.openjdk.org/jdk/pull/8403 From coleenp at openjdk.org Wed Aug 10 22:08:11 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Aug 2022 22:08:11 GMT Subject: RFR: 8292068: Convert ModuleEntryTable into ResourceHashtable [v3] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 18:25:42 GMT, Coleen Phillimore wrote: >> Converted the ModuleEntryTable to use ResourceHashtable. >> Ran tiers 1-7. Also ran performance tests with this and other changes with no performance difference, although the footprint of this should be better. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Revert modules_do() assert Module_lock and taking it for process_module_table. This should be fixed separately. Thanks for the reviews, Ioi and Lois. GHA happy. ------------- PR: https://git.openjdk.org/jdk/pull/9809 From coleenp at openjdk.org Wed Aug 10 22:08:11 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Aug 2022 22:08:11 GMT Subject: Integrated: 8292068: Convert ModuleEntryTable into ResourceHashtable In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 12:27:46 GMT, Coleen Phillimore wrote: > Converted the ModuleEntryTable to use ResourceHashtable. > Ran tiers 1-7. Also ran performance tests with this and other changes with no performance difference, although the footprint of this should be better. This pull request has now been integrated. Changeset: b47438ca Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/b47438cabc5e365910f2a110972431133649fcc4 Stats: 370 lines in 8 files changed: 111 ins; 185 del; 74 mod 8292068: Convert ModuleEntryTable into ResourceHashtable Reviewed-by: iklam, lfoltan ------------- PR: https://git.openjdk.org/jdk/pull/9809 From fjiang at openjdk.org Thu Aug 11 00:52:51 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 11 Aug 2022 00:52:51 GMT Subject: RFR: 8292187: aarch64: Remove duplicate header files In-Reply-To: <8ED_Cc933lakBkbmfOfdSLvL2cRQl4AvKLr8Ahjeo3c=.15503b87-e37a-421a-ae62-d0ac00458684@github.com> References: <8ED_Cc933lakBkbmfOfdSLvL2cRQl4AvKLr8Ahjeo3c=.15503b87-e37a-421a-ae62-d0ac00458684@github.com> Message-ID: On Wed, 10 Aug 2022 14:04:57 GMT, Andrew Haley wrote: >> It's a trivial patch that removes duplicate included header files under hotspot/cpu/aarch64. >> >> aarch64 release and fastdebug build with `--disable-precompiled-headers` passed. > > Marked as reviewed by aph (Reviewer). @theRealAph @nick-arm -- Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9821 From fjiang at openjdk.org Thu Aug 11 00:57:50 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 11 Aug 2022 00:57:50 GMT Subject: Integrated: 8292187: aarch64: Remove duplicate header files In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 12:10:02 GMT, Feilong Jiang wrote: > It's a trivial patch that removes duplicate included header files under hotspot/cpu/aarch64. > > aarch64 release and fastdebug build with `--disable-precompiled-headers` passed. This pull request has now been integrated. Changeset: 2e0a17c5 Author: Feilong Jiang Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/2e0a17c560d821276544d83bee3891633065e2fc Stats: 8 lines in 3 files changed: 1 ins; 7 del; 0 mod 8292187: aarch64: Remove duplicate header files Reviewed-by: aph, ngasson ------------- PR: https://git.openjdk.org/jdk/pull/9821 From kvn at openjdk.org Thu Aug 11 02:00:39 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 11 Aug 2022 02:00:39 GMT Subject: RFR: 8292153: x86: Represent Registers as values [v2] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 21:10:51 GMT, Vladimir Ivanov wrote: >> As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads. >> >> Proposed change hides pointer representation behind value class. >> >> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). >> >> Code quality doesn't suffer (and even slightly improves): >> https://godbolt.org/z/d8dGM1eY1 >> >> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) >> >> Testing: hs-tier1 - hs-tier5 >> >> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > cleanups Looks good to me. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9815 From kvn at openjdk.org Thu Aug 11 02:02:39 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 11 Aug 2022 02:02:39 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 03:12:10 GMT, AJ Ferguson wrote: > Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. Please, add regression test. ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9635 From vlivanov at openjdk.org Thu Aug 11 05:11:41 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 11 Aug 2022 05:11:41 GMT Subject: RFR: 8292203: AArch64: Represent Registers as values Message-ID: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> (It's a PR dependent on #9815.) Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation. The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types. Proposed change hides pointer representation behind value class. Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). Code quality improves: GCC: https://godbolt.org/z/r6G36facj Clang: https://godbolt.org/z/x5oPdYEPM (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) Testing: hs-tier1 - hs-tier5 PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. ------------- Commit messages: - 8292203: AArch64: Represent Registers as values - cleanups - x86: Register class wrappers Changes: https://git.openjdk.org/jdk/pull/9826/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9826&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292203 Stats: 1102 lines in 43 files changed: 273 ins; 156 del; 673 mod Patch: https://git.openjdk.org/jdk/pull/9826.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9826/head:pull/9826 PR: https://git.openjdk.org/jdk/pull/9826 From stuefe at openjdk.org Thu Aug 11 05:26:04 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 11 Aug 2022 05:26:04 GMT Subject: RFR: 8291945: Add OSInfo API for static OS information [v2] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 21:50:17 GMT, Ioi Lam wrote: >> As suggested by @tstuefe in the review of #9600, many of the `os` APIs simply return a value that was initialized during VM start up. E.g., `os::vm_page_size()`. I have added a new class `OSInfo` for managing such info >> >> - Simplifies the per-OS implementation >> - Make the "init-only-once" check consistent >> - In some cases, the simpler `OSInfo` class can be used in lieu of the more complex `os` class. This improves HotSpot build time (e.g., relocInfo.hpp). >> >> Note: I moved only 2 fields in this PR as a first step. If this works well I plan to move more fields in the future. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo Looks good! Cheers, Thomas src/hotspot/share/runtime/osInfo.hpp line 41: > 39: static int vm_page_size() { return _vm_page_size; } > 40: > 41: // Returns the size in bytes of memory blocks which can be allocated. Too vague and a bit misleading. Proposal: `Returns size, in bytes, of the granularity with which memory can be reserved using os::reserve_memory().` ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/9758 From stuefe at openjdk.org Thu Aug 11 06:25:34 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 11 Aug 2022 06:25:34 GMT Subject: RFR: 8290025: Remove the Sweeper [v8] In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 06:10:22 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Redundant variable I ran this patch through our CI. We now see Codecache OOMs in internal tests. These tests were explicitly started with small code caches to see regressions in code cache usage. Unfortunately, these tests are internal, so I cannot share them. Do tests in the open jtreg suite exist that test for code cache size regressions? ------------- PR: https://git.openjdk.org/jdk/pull/9741 From rcastanedalo at openjdk.org Thu Aug 11 07:49:22 2022 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 11 Aug 2022 07:49:22 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 03:12:10 GMT, AJ Ferguson wrote: > Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. Hi @AJ-Ferguson, please note that the [JBS issue](https://bugs.openjdk.org/browse/JDK-8292158) is assigned to @smita-kamath, who wrote the original implementation. Please check with Smita or other regular Intel contributors (e.g. @jatin-bhateja, @sviswa7) before moving forward with this changeset. ------------- PR: https://git.openjdk.org/jdk/pull/9635 From eosterlund at openjdk.org Thu Aug 11 08:15:48 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 11 Aug 2022 08:15:48 GMT Subject: RFR: 8290025: Remove the Sweeper [v9] In-Reply-To: References: Message-ID: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Zhengyu comments v1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9741/files - new: https://git.openjdk.org/jdk/pull/9741/files/3cd50998..fdb26648 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=07-08 Stats: 8 lines in 2 files changed: 1 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9741/head:pull/9741 PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 11 08:15:49 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 11 Aug 2022 08:15:49 GMT Subject: RFR: 8290025: Remove the Sweeper [v8] In-Reply-To: References: Message-ID: <_Pb4uGH44AJIfg1MEYyPlggujtPpmZEyQIDeCjuL284=.26cb4cd1-929b-4de8-814c-58fa056a9c48@github.com> On Tue, 9 Aug 2022 06:10:22 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Redundant variable Thanks for the review @zhengyu123! I Applied the changes you requested. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 11 08:31:37 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 11 Aug 2022 08:31:37 GMT Subject: RFR: 8290025: Remove the Sweeper [v8] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 06:23:12 GMT, Thomas Stuefe wrote: > I ran this patch through our CI. We now see Codecache OOMs in internal tests. > > These tests were explicitly started with small code caches to see regressions in code cache usage. Unfortunately, these tests are internal, so I cannot share them. > > Do tests in the open jtreg suite exist that test for code cache size regressions? Thank you for taking the patch for a spin in your internal testing. Unfortunately, I'm not entirely sure what to do with this information as I can't reproduce it locally, and hence reason whether the test or the new code should be changed. However, it's worth mentioning that there is a minimum number of 2 GCs for nmethods to not be called before they are unloaded due to being cold (cf. CodeCache::update_cold_gc_count). Having just 1 single GC felt like a big risk because then the entire code cache could easily get unloaded, and I don't think I want that to ever happen. It might be that removing that restriction would make your test pass. But if it did, it's far from obvious that doing that would be the right thing. Let me explain why. CodeCache exhaustion is something we can recover from. So the implication of hitting it is that you have to run some things in the interpreter for a while and calm down a bit until code cache can get freed. But aggressively nuking the code cache to make room for JIT compiled code, by reaping very recently used compiled code, also entails that we similarly have to run in the interpreter a *lot*, and on top of that also have all the JIT compilers spin recompiling things that were recently used. While doing that might (again, can't really try my hypothesis) make the test pass, I'm really not sure it's the right thing to do. I get a feeling that if you are this close to exhaustion, that you really should have a larger code cache. Could you share the -Xlog:codecache log information, so that we can see if the heuristics gave it its best shot, or if it was slacking, which would at least be a bug? ------------- PR: https://git.openjdk.org/jdk/pull/9741 From aph at openjdk.org Thu Aug 11 08:48:45 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 11 Aug 2022 08:48:45 GMT Subject: RFR: 8292153: x86: Represent Registers as values [v2] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 21:10:51 GMT, Vladimir Ivanov wrote: >> As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads. >> >> Proposed change hides pointer representation behind value class. >> >> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). >> >> Code quality doesn't suffer (and even slightly improves): >> https://godbolt.org/z/d8dGM1eY1 >> >> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) >> >> Testing: hs-tier1 - hs-tier5 >> >> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > cleanups Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9815 From stuefe at openjdk.org Thu Aug 11 09:12:36 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 11 Aug 2022 09:12:36 GMT Subject: RFR: 8290025: Remove the Sweeper [v8] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 08:27:54 GMT, Erik ?sterlund wrote: > CodeCache exhaustion is something we can recover from. So, Codecache OOMs are not observable? I see in the test log an OOM bubbling up: OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. OpenJDK 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= Thread Thread[#32,Thread-0,5,main] died with java.lang.VirtualMachineError: Out of space in CodeCache for adapters java.lang.VirtualMachineError: Out of space in CodeCache for adapters at java.base/java.time.zone.ZoneRules.readExternal(ZoneRules.java:483) at java.base/java.time.zone.Ser.readInternal(Ser.java:195) at java.base/java.time.zone.Ser.read(Ser.java:189) at java.base/java.time.zone.TzdbZoneRulesProvider.provideRules(TzdbZoneRulesProvider.java:135) at java.base/java.time.zone.ZoneRulesProvider.getRules(ZoneRulesProvider.java:236) at java.base/java.time.ZoneRegion.ofId(ZoneRegion.java:121) at java.base/java.time.ZoneId.of(ZoneId.java:410) at java.base/java.time.ZoneId.of(ZoneId.java:358) at java.base/java.time.ZoneId.of(ZoneId.java:314) at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:581) at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558) at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:570) at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558) at java.base/sun.util.cldr.CLDRTimeZoneNameProviderImpl.getDisplayNameArray(CLDRTimeZoneNameProviderImpl.java:94) at java.base/sun.util.locale.provider.TimeZoneNameProviderImpl.getDisplayName(TimeZoneNameProviderImpl.java:99) at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getName(TimeZoneNameUtility.java:271) at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getObject(TimeZoneNameUtility.java:229) at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getObject(TimeZoneNameUtility.java:215) at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl(LocaleServiceProviderPool.java:275) at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObject(LocaleServiceProviderPool.java:236) at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNamesImpl(TimeZoneNameUtility.java:197) at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayName(TimeZoneNameUtility.java:150) at java.base/java.util.TimeZone.getDisplayName(TimeZone.java:409) at java.base/java.util.TimeZone.getDisplayName(TimeZone.java:372) at com.crystaldecisions.reports.common.TimeZoneUtil.getTimeZoneString(TimeZoneUtil.java:165) > Could you share the -Xlog:codecache log information, so that we can see if the heuristics gave it its best shot, or if it was slacking, which would at least be a bug? I can try, but I have not much time atm and no easy access to the failing test. I'll see what I can do. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 11 09:41:32 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 11 Aug 2022 09:41:32 GMT Subject: RFR: 8290025: Remove the Sweeper [v8] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 09:08:41 GMT, Thomas Stuefe wrote: > > CodeCache exhaustion is something we can recover from. > > So, Codecache OOMs are not observable? I see in the test log an OOM bubbling up: > > ``` > OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. > OpenJDK 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= > Thread Thread[#32,Thread-0,5,main] died with java.lang.VirtualMachineError: Out of space in CodeCache for adapters > java.lang.VirtualMachineError: Out of space in CodeCache for adapters > at java.base/java.time.zone.ZoneRules.readExternal(ZoneRules.java:483) > at java.base/java.time.zone.Ser.readInternal(Ser.java:195) > at java.base/java.time.zone.Ser.read(Ser.java:189) > at java.base/java.time.zone.TzdbZoneRulesProvider.provideRules(TzdbZoneRulesProvider.java:135) > at java.base/java.time.zone.ZoneRulesProvider.getRules(ZoneRulesProvider.java:236) > at java.base/java.time.ZoneRegion.ofId(ZoneRegion.java:121) > at java.base/java.time.ZoneId.of(ZoneId.java:410) > at java.base/java.time.ZoneId.of(ZoneId.java:358) > at java.base/java.time.ZoneId.of(ZoneId.java:314) > at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:581) > at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558) > at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:570) > at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558) > at java.base/sun.util.cldr.CLDRTimeZoneNameProviderImpl.getDisplayNameArray(CLDRTimeZoneNameProviderImpl.java:94) > at java.base/sun.util.locale.provider.TimeZoneNameProviderImpl.getDisplayName(TimeZoneNameProviderImpl.java:99) > at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getName(TimeZoneNameUtility.java:271) > at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getObject(TimeZoneNameUtility.java:229) > at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getObject(TimeZoneNameUtility.java:215) > at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl(LocaleServiceProviderPool.java:275) > at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObject(LocaleServiceProviderPool.java:236) > at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNamesImpl(TimeZoneNameUtility.java:197) > at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayName(TimeZoneNameUtility.java:150) > at java.base/java.util.TimeZone.getDisplayName(TimeZone.java:409) > at java.base/java.util.TimeZone.getDisplayName(TimeZone.java:372) > at com.crystaldecisions.reports.common.TimeZoneUtil.getTimeZoneString(TimeZoneUtil.java:165) > ``` > > > Could you share the -Xlog:codecache log information, so that we can see if the heuristics gave it its best shot, or if it was slacking, which would at least be a bug? > > I can try, but I have not much time atm and no easy access to the failing test. I'll see what I can do. Thank you for the log. This does look like a problem. In an earlier version I had a hook to provoke GCs from adapter allocations, but removed it because I thought they shouldn't share code cache with nmethods. But I think that assumption was incorrect. I'll look into it. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From stuefe at openjdk.org Thu Aug 11 10:02:39 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 11 Aug 2022 10:02:39 GMT Subject: RFR: 8290025: Remove the Sweeper [v9] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 08:15:48 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Zhengyu comments v1 A general question, since we now need full GCs for sweeping the code cache, would a too-tight code cache now hurt more than before? Similar to how a too small metaspace could result in excessive GCs today? ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 11 10:43:34 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 11 Aug 2022 10:43:34 GMT Subject: RFR: 8290025: Remove the Sweeper [v9] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 09:58:43 GMT, Thomas Stuefe wrote: > A general question, since we now need full GCs for sweeping the code cache, would a too-tight code cache now hurt more than before? Similar to how a too small metaspace could result in excessive GCs today? Yes that would hurt more, unless you use loom. If you use loom the sweeper does a full GC to scan stacks in the heap, which is much worse. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 11 11:49:25 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 11 Aug 2022 11:49:25 GMT Subject: Integrated: 8292077: G1 nmethod entry barriers don't keep oops alive In-Reply-To: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> References: <8G2LVF2ygGFbjJ6w-qSvjxSN8GwVbMors0rkmkf1SEY=.12373c4e-cfe2-45f4-b72d-2fac71fc0400@github.com> Message-ID: On Wed, 10 Aug 2022 09:01:59 GMT, Erik ?sterlund wrote: > The intention is that when G1 uses nmethod entry barriers (currently with --enable-preview to support Loom, but soon also with https://bugs.openjdk.org/browse/JDK-8290025), it keeps nmethod oops alive the first time an nmethod becomes on-stack during concurrent marking. The current code fails to do that, even though it intended to. That should be fixed. > > There was code from loom to keep the oops alive by performing a phantom load. However, there is a quirk with the access API; if you don't assign the result of the load to something, the load won't be performed, and hence the oop won't be kept alive. I changed the code to use CollectedHeap::keep_alive explicitly instead of relying on side effects of a dummy load. > I also found that we assume G1 concurrent marking isn't aborted more than once. But that can happen. I made the assumption more conservative - surely if there are INT_MAX - 1 interrupted concurrent GCs in a row... something is very very wrong. This pull request has now been integrated. Changeset: 1c0f0f42 Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/1c0f0f4211cf564c46753d2cb187c1ef485751cd Stats: 30 lines in 1 file changed: 19 ins; 9 del; 2 mod 8292077: G1 nmethod entry barriers don't keep oops alive Reviewed-by: tschatzl, stefank, vlivanov ------------- PR: https://git.openjdk.org/jdk/pull/9817 From coleenp at openjdk.org Thu Aug 11 12:48:02 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Aug 2022 12:48:02 GMT Subject: RFR: 8292218: Convert PackageEntryTable to ResourceHashtable Message-ID: This is the conversion of the PackageEntryTable, which is stored one per ClassLoaderData to ResourceHashtable. Much like the module table and uses the Module_lock. Tested with tier1-3 on linux, windows, mac. ------------- Commit messages: - Fix bug and anticipated code review comment and made ModuleEntryTable destructor look like the package one (inlined the class) - 8292218: Convert PackageEntryTable to ResourceHashtable Changes: https://git.openjdk.org/jdk/pull/9837/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9837&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292218 Stats: 300 lines in 8 files changed: 71 ins; 133 del; 96 mod Patch: https://git.openjdk.org/jdk/pull/9837.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9837/head:pull/9837 PR: https://git.openjdk.org/jdk/pull/9837 From eosterlund at openjdk.org Thu Aug 11 13:44:00 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 11 Aug 2022 13:44:00 GMT Subject: RFR: 8290025: Remove the Sweeper [v10] In-Reply-To: References: Message-ID: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Trigger GC from adapter blob allocations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9741/files - new: https://git.openjdk.org/jdk/pull/9741/files/fdb26648..8c011d7c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=08-09 Stats: 5 lines in 2 files changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9741/head:pull/9741 PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 11 13:50:38 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 11 Aug 2022 13:50:38 GMT Subject: RFR: 8290025: Remove the Sweeper [v9] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 09:58:43 GMT, Thomas Stuefe wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Zhengyu comments v1 > > A general question, since we now need full GCs for sweeping the code cache, would a too-tight code cache now hurt more than before? Similar to how a too small metaspace could result in excessive GCs today? @tstuefe I reintroduced the heuristics poke from adapter blob allocations. It very well might fix the failure. If you find the time to re-run the test, that would be very appreciated. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9741 From lfoltan at openjdk.org Thu Aug 11 16:15:41 2022 From: lfoltan at openjdk.org (Lois Foltan) Date: Thu, 11 Aug 2022 16:15:41 GMT Subject: RFR: 8292218: Convert PackageEntryTable to ResourceHashtable In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 12:20:47 GMT, Coleen Phillimore wrote: > This is the conversion of the PackageEntryTable, which is stored one per ClassLoaderData to ResourceHashtable. Much like the module table and uses the Module_lock. > Tested with tier1-3 on linux, windows, mac. src/hotspot/share/classfile/packageEntry.cpp line 202: > 200: log_info(module, unload)("unloading package %s", str); > 201: log_debug(module)("PackageEntry: deleting module: %s", str); > 202: } Not "deleting module" but "deleting package" src/hotspot/share/classfile/packageEntry.cpp line 283: > 281: int n = 0; > 282: auto count = [&] (const Symbol*& key, PackageEntry*& p) { > 283: if (p->module()->name() != NULL) { The better way to check for the unnamed module is to use the ModuleEntry::is_named() method. src/hotspot/share/classfile/packageEntry.cpp line 293: > 291: n = 0; > 292: auto grab = [&] (const Symbol*& key, PackageEntry*& p) { > 293: if (p->module()->name() != NULL) { The better way to check for the unnamed module is to use the ModuleEntry::is_named() method ------------- PR: https://git.openjdk.org/jdk/pull/9837 From lfoltan at openjdk.org Thu Aug 11 16:15:42 2022 From: lfoltan at openjdk.org (Lois Foltan) Date: Thu, 11 Aug 2022 16:15:42 GMT Subject: RFR: 8292218: Convert PackageEntryTable to ResourceHashtable In-Reply-To: References: Message-ID: <7UDIPbjnml4B2qBBU1rGM0C4sVEkZRwy-7f3r6vpYzg=.626c7bf1-61b1-448b-96e4-d63c15d7eca9@github.com> On Thu, 11 Aug 2022 16:07:55 GMT, Lois Foltan wrote: >> This is the conversion of the PackageEntryTable, which is stored one per ClassLoaderData to ResourceHashtable. Much like the module table and uses the Module_lock. >> Tested with tier1-3 on linux, windows, mac. > > src/hotspot/share/classfile/packageEntry.cpp line 202: > >> 200: log_info(module, unload)("unloading package %s", str); >> 201: log_debug(module)("PackageEntry: deleting module: %s", str); >> 202: } > > Not "deleting module" but "deleting package" And maybe these logging comments are more appropriately placed in ~PackageEntry? ------------- PR: https://git.openjdk.org/jdk/pull/9837 From duke at openjdk.org Thu Aug 11 19:13:30 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Thu, 11 Aug 2022 19:13:30 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 15:18:10 GMT, Johan Sj?l?n wrote: > May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? > > This PR does 3 things: > > * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot > * Adds some new utilities for writing multi-threaded tests. > * Adds some tests for MRSW Mutex using these new utilities > > The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 > > [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp src/hotspot/share/runtime/mrswMutex.hpp line 105: > 103: > 104: // Do requested transition before blocking > 105: WriterTransition tbivm(JavaThread::current()); This shouldn't compute the thread, instead `read_lock` and `write_lock` should be given the threads as arguments. This will fail if the current thread isn't a Java one. src/hotspot/share/runtime/mrswMutex.hpp line 149: > 147: > 148: // Do requested transition before blocking > 149: ReaderTransition tbivm(JavaThread::current()); This shouldn't compute the thread, instead `read_lock` and `write_lock` should be given the threads as arguments. This will fail if the current thread isn't a Java one. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From coleenp at openjdk.org Thu Aug 11 19:15:45 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Aug 2022 19:15:45 GMT Subject: RFR: 8292218: Convert PackageEntryTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: > This is the conversion of the PackageEntryTable, which is stored one per ClassLoaderData to ResourceHashtable. Much like the module table and uses the Module_lock. > Tested with tier1-3 on linux, windows, mac. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix debug info and module name comparison. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9837/files - new: https://git.openjdk.org/jdk/pull/9837/files/ebb1e95a..b813b6c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9837&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9837&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9837.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9837/head:pull/9837 PR: https://git.openjdk.org/jdk/pull/9837 From coleenp at openjdk.org Thu Aug 11 19:15:47 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Aug 2022 19:15:47 GMT Subject: RFR: 8292218: Convert PackageEntryTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 19:10:39 GMT, Coleen Phillimore wrote: >> This is the conversion of the PackageEntryTable, which is stored one per ClassLoaderData to ResourceHashtable. Much like the module table and uses the Module_lock. >> Tested with tier1-3 on linux, windows, mac. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix debug info and module name comparison. @lfoltan thank you for the comments and reviewing the code. ------------- PR: https://git.openjdk.org/jdk/pull/9837 From coleenp at openjdk.org Thu Aug 11 19:15:48 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Aug 2022 19:15:48 GMT Subject: RFR: 8292218: Convert PackageEntryTable to ResourceHashtable [v2] In-Reply-To: <7UDIPbjnml4B2qBBU1rGM0C4sVEkZRwy-7f3r6vpYzg=.626c7bf1-61b1-448b-96e4-d63c15d7eca9@github.com> References: <7UDIPbjnml4B2qBBU1rGM0C4sVEkZRwy-7f3r6vpYzg=.626c7bf1-61b1-448b-96e4-d63c15d7eca9@github.com> Message-ID: On Thu, 11 Aug 2022 16:09:06 GMT, Lois Foltan wrote: >> src/hotspot/share/classfile/packageEntry.cpp line 202: >> >>> 200: log_info(module, unload)("unloading package %s", str); >>> 201: log_debug(module)("PackageEntry: deleting module: %s", str); >>> 202: } >> >> Not "deleting module" but "deleting package" > > And maybe these logging comments are more appropriately placed in ~PackageEntry? I fixed the message. I liked this idea but when I tried to move this one and the similar one in module (so that they're the same), I had two problems. The module's name can be null in the destructor (for the unnamed module) so the logging statement crashed so would need more conditionals. For package entries, there's a put_if_absent() so I have a destructor call for the case that the entry isn't absent, which would then log that it had been unloaded. So that would have been bad. So I moved it and then back to where it started. ------------- PR: https://git.openjdk.org/jdk/pull/9837 From coleenp at openjdk.org Thu Aug 11 19:15:53 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Aug 2022 19:15:53 GMT Subject: RFR: 8292218: Convert PackageEntryTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: <0Hn6W5y1HDpK1S_IDtXQz5INjeS8TH4ofLsc4k5oroI=.d0fcb25b-7d0e-418b-8b3a-e542f79bb11b@github.com> On Thu, 11 Aug 2022 16:11:21 GMT, Lois Foltan wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix debug info and module name comparison. > > src/hotspot/share/classfile/packageEntry.cpp line 283: > >> 281: int n = 0; >> 282: auto count = [&] (const Symbol*& key, PackageEntry*& p) { >> 283: if (p->module()->name() != NULL) { > > The better way to check for the unnamed module is to use the ModuleEntry::is_named() method. Fixed. > src/hotspot/share/classfile/packageEntry.cpp line 293: > >> 291: n = 0; >> 292: auto grab = [&] (const Symbol*& key, PackageEntry*& p) { >> 293: if (p->module()->name() != NULL) { > > The better way to check for the unnamed module is to use the ModuleEntry::is_named() method Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/9837 From eosterlund at openjdk.org Thu Aug 11 19:31:36 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 11 Aug 2022 19:31:36 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 15:18:10 GMT, Johan Sj?l?n wrote: > May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? > > This PR does 3 things: > > * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot > * Adds some new utilities for writing multi-threaded tests. > * Adds some tests for MRSW Mutex using these new utilities > > The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 > > [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp 64 bit cmpxchg isn't available for some 32 bit CPUs. Maybe it could be int32_t? ------------- PR: https://git.openjdk.org/jdk/pull/9838 From kvn at openjdk.org Thu Aug 11 19:52:16 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 11 Aug 2022 19:52:16 GMT Subject: RFR: 8292203: AArch64: Represent Registers as values In-Reply-To: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> Message-ID: On Wed, 10 Aug 2022 21:44:50 GMT, Vladimir Ivanov wrote: > (It's a PR dependent on #9815.) > > Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation. > > The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types. > > Proposed change hides pointer representation behind value class. > > Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). > > Code quality improves: > GCC: https://godbolt.org/z/r6G36facj > Clang: https://godbolt.org/z/x5oPdYEPM > > (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) > > Testing: hs-tier1 - hs-tier5 > > PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. I looked on aarch64 changes. Looks fine. The rest come from #9815 as I understand. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9826 From lfoltan at openjdk.org Thu Aug 11 20:15:08 2022 From: lfoltan at openjdk.org (Lois Foltan) Date: Thu, 11 Aug 2022 20:15:08 GMT Subject: RFR: 8292218: Convert PackageEntryTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 19:15:45 GMT, Coleen Phillimore wrote: >> This is the conversion of the PackageEntryTable, which is stored one per ClassLoaderData to ResourceHashtable. Much like the module table and uses the Module_lock. >> Tested with tier1-3 on linux, windows, mac. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix debug info and module name comparison. Thanks Coleen, looks good. I've added just one more minor comment. Lois src/hotspot/share/classfile/packageEntry.cpp line 201: > 199: const char* str = name->as_C_string(); > 200: log_info(module, unload)("unloading package %s", str); > 201: log_debug(module)("PackageEntry: deleting package: %s", str); A real nit but to be consistent with ModuleEntryTable::~ModuleEntryTable() maybe change "PackageEntry:" to "PackageEntryTable:" ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.org/jdk/pull/9837 From kvn at openjdk.org Thu Aug 11 20:47:59 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 11 Aug 2022 20:47:59 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v5] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 21:18:11 GMT, Evgeny Astigeevich wrote: >> Runtime calls are calls of non-compiled methods. Non-compiled methods stay forever in CodeCache. If they are always within the branch range, they don't need trampolines. >> >> This PR adds `is_always_within_branch_range(Address entry)`. >> >> Results from DaCapo: the total number of eliminated trampolines per a benchmark run >> >> >> +----------+--------+ >> | avrora | 15491 | >> | batik | 75837 | >> | biojava | 13927 | >> | eclipse | 414143 | >> | fop | 119267 | >> | graphchi | 7665 | >> | jme | 8279 | >> | luindex | 56061 | >> | lusearch | 50277 | >> | pmd | 132719 | >> | sunflow | 10689 | >> | tomcat | 186967 | >> | xalan | 50349 | >> | zxing | 41497 | >> +----------+--------+ >> >> >> >> Testing: >> - `tier1`...`tier2`: Passed >> - `compiler/c2/aarch64/TestTrampoline.java`: Passed >> >> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Combine @requires; Change is_always_reachable to is_always_within_branch_range Good. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 878: > 876: // Runtime calls are calls of a non-compiled method. > 877: // Non-compiled methods stay forever in CodeCache. > 878: // We check whether the longest possible branch is within the branch range. I think you should add clarification "non-compiled method (stubs, adapters)". ------------- PR: https://git.openjdk.org/jdk/pull/8403 From vlivanov at openjdk.org Thu Aug 11 21:17:00 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 11 Aug 2022 21:17:00 GMT Subject: RFR: 8292153: x86: Represent Registers as values [v2] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 21:10:51 GMT, Vladimir Ivanov wrote: >> As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads. >> >> Proposed change hides pointer representation behind value class. >> >> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). >> >> Code quality doesn't suffer (and even slightly improves): >> https://godbolt.org/z/d8dGM1eY1 >> >> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) >> >> Testing: hs-tier1 - hs-tier5 >> >> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > cleanups Thanks for the reviews, Vladimir and Andrew. ------------- PR: https://git.openjdk.org/jdk/pull/9815 From duke at openjdk.org Thu Aug 11 21:19:07 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Thu, 11 Aug 2022 21:19:07 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v6] In-Reply-To: References: Message-ID: > Runtime calls are calls of non-compiled methods. Non-compiled methods stay forever in CodeCache. If they are always within the branch range, they don't need trampolines. > > This PR adds `is_always_within_branch_range(Address entry)`. > > Results from DaCapo: the total number of eliminated trampolines per a benchmark run > > > +----------+--------+ > | avrora | 15491 | > | batik | 75837 | > | biojava | 13927 | > | eclipse | 414143 | > | fop | 119267 | > | graphchi | 7665 | > | jme | 8279 | > | luindex | 56061 | > | lusearch | 50277 | > | pmd | 132719 | > | sunflow | 10689 | > | tomcat | 186967 | > | xalan | 50349 | > | zxing | 41497 | > +----------+--------+ > > > > Testing: > - `tier1`...`tier2`: Passed > - `compiler/c2/aarch64/TestTrampoline.java`: Passed > > Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Clarify non-compiled method in comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8403/files - new: https://git.openjdk.org/jdk/pull/8403/files/4db9dfc9..55872c47 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8403&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8403&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/8403.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8403/head:pull/8403 PR: https://git.openjdk.org/jdk/pull/8403 From duke at openjdk.org Thu Aug 11 21:19:11 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Thu, 11 Aug 2022 21:19:11 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v5] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 20:41:44 GMT, Vladimir Kozlov wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Combine @requires; Change is_always_reachable to is_always_within_branch_range > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 878: > >> 876: // Runtime calls are calls of a non-compiled method. >> 877: // Non-compiled methods stay forever in CodeCache. >> 878: // We check whether the longest possible branch is within the branch range. > > I think you should add clarification "non-compiled method (stubs, adapters)". Thank you for reviewing. Done. ------------- PR: https://git.openjdk.org/jdk/pull/8403 From vlivanov at openjdk.org Thu Aug 11 21:19:58 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 11 Aug 2022 21:19:58 GMT Subject: Integrated: 8292153: x86: Represent Registers as values In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 23:25:27 GMT, Vladimir Ivanov wrote: > As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads. > > Proposed change hides pointer representation behind value class. > > Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). > > Code quality doesn't suffer (and even slightly improves): > https://godbolt.org/z/d8dGM1eY1 > > (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) > > Testing: hs-tier1 - hs-tier5 > > PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. This pull request has now been integrated. Changeset: 755ecf6b Author: Vladimir Ivanov URL: https://git.openjdk.org/jdk/commit/755ecf6b7384e67ccb51c4498f94336631db690d Stats: 575 lines in 28 files changed: 152 ins; 103 del; 320 mod 8292153: x86: Represent Registers as values Reviewed-by: kvn, aph ------------- PR: https://git.openjdk.org/jdk/pull/9815 From vlivanov at openjdk.org Thu Aug 11 21:24:37 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 11 Aug 2022 21:24:37 GMT Subject: RFR: 8292203: AArch64: Represent Registers as values [v2] In-Reply-To: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> Message-ID: > (It's a PR dependent on #9815.) > > Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation. > > The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types. > > Proposed change hides pointer representation behind value class. > > Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). > > Code quality improves: > GCC: https://godbolt.org/z/r6G36facj > Clang: https://godbolt.org/z/x5oPdYEPM > > (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) > > Testing: hs-tier1 - hs-tier5 > > PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into rwrapper.aarch64 - 8292203: AArch64: Represent Registers as values - cleanups - x86: Register class wrappers ------------- Changes: https://git.openjdk.org/jdk/pull/9826/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9826&range=01 Stats: 527 lines in 15 files changed: 121 ins; 53 del; 353 mod Patch: https://git.openjdk.org/jdk/pull/9826.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9826/head:pull/9826 PR: https://git.openjdk.org/jdk/pull/9826 From iklam at openjdk.org Thu Aug 11 21:37:58 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 11 Aug 2022 21:37:58 GMT Subject: RFR: 8292218: Convert PackageEntryTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 19:15:45 GMT, Coleen Phillimore wrote: >> This is the conversion of the PackageEntryTable, which is stored one per ClassLoaderData to ResourceHashtable. Much like the module table and uses the Module_lock. >> Tested with tier1-3 on linux, windows, mac. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix debug info and module name comparison. LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/9837 From iklam at openjdk.org Thu Aug 11 22:27:50 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 11 Aug 2022 22:27:50 GMT Subject: RFR: 8291945: Add OSInfo API for static OS information [v3] In-Reply-To: References: Message-ID: <6Zmz8-MKGu7c3sNHn_3MD16g1hns4LNhqOpbJTRTVJQ=.2f419978-a227-4f79-b960-f3e6ecdd7475@github.com> > As suggested by @tstuefe in the review of #9600, many of the `os` APIs simply return a value that was initialized during VM start up. E.g., `os::vm_page_size()`. I have added a new class `OSInfo` for managing such info > > - Simplifies the per-OS implementation > - Make the "init-only-once" check consistent > - In some cases, the simpler `OSInfo` class can be used in lieu of the more complex `os` class. This improves HotSpot build time (e.g., relocInfo.hpp). > > Note: I moved only 2 fields in this PR as a first step. If this works well I plan to move more fields in the future. 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' of https://github.com/openjdk/jdk into 8291945-add-OSInfo-api - @tstuefe review -- clarify comments - fixed typo - fixed zero build; added comments - 8291945: Add OSInfo API for static OS information ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9758/files - new: https://git.openjdk.org/jdk/pull/9758/files/3da77fcb..faa28f65 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9758&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9758&range=01-02 Stats: 7721 lines in 347 files changed: 4361 ins; 2178 del; 1182 mod Patch: https://git.openjdk.org/jdk/pull/9758.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9758/head:pull/9758 PR: https://git.openjdk.org/jdk/pull/9758 From iklam at openjdk.org Thu Aug 11 23:08:42 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 11 Aug 2022 23:08:42 GMT Subject: RFR: 8291945: Add OSInfo API for static OS information In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 05:05:50 GMT, David Holmes wrote: >> As suggested by @tstuefe in the review of #9600, many of the `os` APIs simply return a value that was initialized during VM start up. E.g., `os::vm_page_size()`. I have added a new class `OSInfo` for managing such info >> >> - Simplifies the per-OS implementation >> - Make the "init-only-once" check consistent >> - In some cases, the simpler `OSInfo` class can be used in lieu of the more complex `os` class. This improves HotSpot build time (e.g., relocInfo.hpp). >> >> Note: I moved only 2 fields in this PR as a first step. If this works well I plan to move more fields in the future. > > Okay I think it would be good to switch to the OSInfo API in the future, so that we reduce the scope of os even further and more clearly delineate an API to request services from the OS, and a simple query API for the OS. Thanks @dholmes-ora and @tstuefe for the review. ------------- PR: https://git.openjdk.org/jdk/pull/9758 From iklam at openjdk.org Thu Aug 11 23:21:04 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 11 Aug 2022 23:21:04 GMT Subject: Integrated: 8291945: Add OSInfo API for static OS information In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 23:18:35 GMT, Ioi Lam wrote: > As suggested by @tstuefe in the review of #9600, many of the `os` APIs simply return a value that was initialized during VM start up. E.g., `os::vm_page_size()`. I have added a new class `OSInfo` for managing such info > > - Simplifies the per-OS implementation > - Make the "init-only-once" check consistent > - In some cases, the simpler `OSInfo` class can be used in lieu of the more complex `os` class. This improves HotSpot build time (e.g., relocInfo.hpp). > > Note: I moved only 2 fields in this PR as a first step. If this works well I plan to move more fields in the future. This pull request has now been integrated. Changeset: 9bfffa08 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/9bfffa082e85372ec39a0fdab6d5f2c175162246 Stats: 213 lines in 17 files changed: 108 ins; 68 del; 37 mod 8291945: Add OSInfo API for static OS information Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/9758 From iklam at openjdk.org Fri Aug 12 03:15:02 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 12 Aug 2022 03:15:02 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp Message-ID: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Fix two problems with synchronizer.hpp: - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. These headers are included much less after this PR (out of ~1000 hotspot .o files) linkedlist.hpp 857 -> 101 synchronizer.hpp 848 -> 122 resourceHash.hpp 850 -> 270 ------------- Commit messages: - added back inlined functions in case their performance matters - fixed copyright - 8292267: Clean up synchronizer.hpp Changes: https://git.openjdk.org/jdk/pull/9849/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9849&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292267 Stats: 54 lines in 21 files changed: 27 ins; 20 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9849.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9849/head:pull/9849 PR: https://git.openjdk.org/jdk/pull/9849 From dholmes at openjdk.org Fri Aug 12 04:48:17 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Aug 2022 04:48:17 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 15:18:10 GMT, Johan Sj?l?n wrote: > May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? > > This PR does 3 things: > > * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot > * Adds some new utilities for writing multi-threaded tests. > * Adds some tests for MRSW Mutex using these new utilities > > The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 > > [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > Multi-Reader Single-Writer mutex Sorry to bikeshed but such a thing is called a ReadWriteLock or a ReadersWriterLock or something similar - can we please use familiar nomenclature here (even rwlock as per POSIX). "mutex" is a contraction of mutual-exclusion and as readers are not mutually exclusive it is an oxymoron to talk about a "multi-reader mutex". Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From dholmes at openjdk.org Fri Aug 12 05:25:32 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Aug 2022 05:25:32 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 15:18:10 GMT, Johan Sj?l?n wrote: > May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? > > This PR does 3 things: > > * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot > * Adds some new utilities for writing multi-threaded tests. > * Adds some tests for MRSW Mutex using these new utilities > > The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 > > [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp Hi Johan, A few initial comments/queries. Thanks. src/hotspot/share/runtime/mrswMutex.hpp line 40: > 38: // If a transition needs to occur when the reader or writer lock is taken (in > 39: // case the thread blocks), then specialize on the ReaderTransition and/or > 40: // WriterTransition parameters. This lock is unfair, high contention of readers It is not clear why we are using template methods here to control the transition. Is this to allow use by different kinds of threads? There are AFAIK only two choices: ThreadBlockInVM for JavaThreads else nothing for other kinds of threads. ?? src/hotspot/share/runtime/mrswMutex.hpp line 45: > 43: // current readers to proceed. The consequences are undefined if one or more > 44: // writer threads attempt to enter their critical region when another writer > 45: // thread already is attempting to do so or currently is in its critical region. Are you saying that this is truly restricted to only a single thread being allowed to use this in write mode, rather than just the normal one-writer-at-a-time? Or is this simply saying the order in which multiple writers are processed is not defined? The description should mention whether the locks are reentrant and whether a writer can downgrade to a read-lock, or implicitly take the read lock in a nested fashion; and also whether a reader can upgrade to a writelock. src/hotspot/share/runtime/mrswMutex.hpp line 56: > 54: > 55: template > 56: class Locker : public StackObj { Why does this need to be a template? We only use it with PlatformMonitor. src/hotspot/share/runtime/mrswMutex.hpp line 135: > 133: } > 134: > 135: // Blocked. Blocked or locked ? ------------- PR: https://git.openjdk.org/jdk/pull/9838 From dholmes at openjdk.org Fri Aug 12 05:25:33 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Aug 2022 05:25:33 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 18:54:50 GMT, Johan Sj?l?n wrote: >> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? >> >> This PR does 3 things: >> >> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot >> * Adds some new utilities for writing multi-threaded tests. >> * Adds some tests for MRSW Mutex using these new utilities >> >> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 >> >> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > > src/hotspot/share/runtime/mrswMutex.hpp line 105: > >> 103: >> 104: // Do requested transition before blocking >> 105: WriterTransition tbivm(JavaThread::current()); > > This shouldn't compute the thread, instead `read_lock` and `write_lock` should be given the threads as arguments. This will fail if the current thread isn't a Java one. It makes sense to pass in the current thread given that the caller already needs to know to select the right transition. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From dholmes at openjdk.org Fri Aug 12 05:29:31 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Aug 2022 05:29:31 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 19:28:17 GMT, Erik ?sterlund wrote: > 64 bit cmpxchg isn't available for some 32 bit CPUs. Maybe it could be int32_t? Right. AFAICS only ARMv6 would be affected by this - does anyone still build for that? (grep for SUPPORTS_NATIVE_CX8). But a 32-bit count should be more than adequate. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From dholmes at openjdk.org Fri Aug 12 05:29:32 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Aug 2022 05:29:32 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: <77GANWr8ZxSXu8jig1h8CEZzj3rS52QHwJjW8z6QmNE=.d9c841a0-d2d7-4a0d-83e8-9ef394b167c9@github.com> On Thu, 11 Aug 2022 15:18:10 GMT, Johan Sj?l?n wrote: > May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? > > This PR does 3 things: > > * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot > * Adds some new utilities for writing multi-threaded tests. > * Adds some tests for MRSW Mutex using these new utilities > > The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 > > [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp Forgot to mention the code in the header file seems rather involved for a .hpp file - should these be in a .inline.hpp file instead? Also did you establish this RW-lock will in fact be usable in this form for UL? ------------- PR: https://git.openjdk.org/jdk/pull/9838 From dholmes at openjdk.org Fri Aug 12 05:42:33 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Aug 2022 05:42:33 GMT Subject: RFR: 8292218: Convert PackageEntryTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 19:15:45 GMT, Coleen Phillimore wrote: >> This is the conversion of the PackageEntryTable, which is stored one per ClassLoaderData to ResourceHashtable. Much like the module table and uses the Module_lock. >> Tested with tier1-3 on linux, windows, mac. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix debug info and module name comparison. Hi Coleen, This looks good to me too. It was a good exercise to observe the conversion. The new code is much cleaner. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9837 From stuefe at openjdk.org Fri Aug 12 05:52:22 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 12 Aug 2022 05:52:22 GMT Subject: RFR: 8290025: Remove the Sweeper [v10] In-Reply-To: References: Message-ID: <_8nIck2Vg8ohdkc-2wA5A6aVP-C_nnKutOn9QEasq08=.7d679de2-314f-45b0-8b87-1f1cc33673d4@github.com> On Thu, 11 Aug 2022 13:44:00 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Trigger GC from adapter blob allocations Hi Erik, Fewer OOMs but still there: java.lang.VirtualMachineError: Out of space in CodeCache for adapters at com.businessobjects.reports.reportconverter.v12.V12SavedDataForwardConverter.convertSavedData(V12SavedDataForwardConverter.java:662) at com.businessobjects.reports.reportconverter.v12.V12SavedDataForwardConverter.convertOneDataSource(V12SavedDataForwardConverter.java:572) at com.businessobjects.reports.reportconverter.v12.V12SavedDataForwardConverter.convertDataSources(V12SavedDataForwardConverter.java:501) at com.businessobjects.reports.reportconverter.v12.V12SavedDataForwardConverter.convert(V12SavedDataForwardConverter.java:289) at com.businessobjects.reports.reportconverter.v12.V12Converter.convertOldToNew(V12Converter.java:247) at com.businessobjects.reports.reportconverter.v12.V12SaveLoader.load(V12SaveLoader.java:263) at com.businessobjects.reports.reportconverter.v12.V12SaveLoader.load(V12SaveLoader.java:139) at com.businessobjects.reports.loader.ReportLoader.loadHelper(ReportLoader.java:245) at com.businessobjects.reports.loader.ReportLoader.load(ReportLoader.java:202) at testapps.performance.TestCaseRunner.operationLoadReport(TestCaseRunner.java:633) at testapps.performance.TestCases.testGotoFirstPage(TestCases.java:110) at testapps.performance.TestCases.runTestCases(TestCases.java:335) at testapps.performance.Runner.run(Runner.java:84) at java.base/java.lang.Thread.run(Thread.java:1589) ``` Crashes on ppcle (during build, no hs-err file remained): * For target jdk__optimize_image_exec: # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/g1BarrierSet.inline.hpp:39 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxppc64le/jdk-dev/src/hotspot/share/gc/g1/g1BarrierSet.inline.hpp:39), pid=27195, tid=27200 # assert(oopDesc::is_oop(pre_val, true)) failed: Error # # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.openjdk.jdk-dev) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.openjdk.jdk-dev, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-ppc64le) # Problematic frame: # V [libjvm.so+0xc5532c] G1BarrierSet::enqueue_preloaded(oop)+0x28c # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # Crash on x64 in vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java (hs-err attached): # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxx86_64/jdk-dev/src/hotspot/share/prims/jvmtiExport.cpp:1700), pid=2633450, tid=2633476 # assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking # [hs_err_pid2633450.log](https://github.com/openjdk/jdk/files/9313935/hs_err_pid2633450.log) ------------- PR: https://git.openjdk.org/jdk/pull/9741 From rehn at openjdk.org Fri Aug 12 06:25:10 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 12 Aug 2022 06:25:10 GMT Subject: RFR: 8291972: Fix double copy of arguments when thawing two interpreted frames In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 14:41:56 GMT, Patricio Chilano Mateo wrote: > When thawing two consecutive interpreted frames the current code makes room in the stack and copies the callee arguments twice, once in the caller and once in the callee. This duplication could use more stack space than the calculation made in prepare_thaw() for the maximum stack space that will be needed during thaw. If that's the case then we will hit an assert that we are writing pass the allowed limit. > Today we don't see this issue though because the only case where we could thaw two interpreter frames is the first time after a freeze. The thawed frames are always Continuation.yield and Continuation.yield0 and the extra used space is only 3 words(yield0's three arguments) which will never exceed the calculation made in prepare_thaw(). > The issue can be made visible when changing the number of frames we thaw when hitting a return barrier from 1 to 2 and running test Continuation/Basic.java. > > This patch fixes this by adjusting the calculated size of the callee frame in new_stack_frame() so that we use the space for the arguments already allocated by the caller. > > Tested the patch by changing the number of thaw frames from 1 to 2 and running all tests in jdk/internal/vm/Continuation/ and jdk/java/lang/Thread/virtual. Also run tiers1-3 in mach5 and loom-tiers1-4. > > Thanks, > Patricio Thank you! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9774 From eosterlund at openjdk.org Fri Aug 12 07:06:30 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 12 Aug 2022 07:06:30 GMT Subject: RFR: 8290025: Remove the Sweeper [v10] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 13:44:00 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Trigger GC from adapter blob allocations Hi Thomas, Thank you for running the tests again for me. > Hi Erik, > > Fewer OOMs but still there: > > ``` > java.lang.VirtualMachineError: Out of space in CodeCache for adapters > at com.businessobjects.reports.reportconverter.v12.V12SavedDataForwardConverter.convertSavedData(V12SavedDataForwardConverter.java:662) > at com.businessobjects.reports.reportconverter.v12.V12SavedDataForwardConverter.convertOneDataSource(V12SavedDataForwardConverter.java:572) > at com.businessobjects.reports.reportconverter.v12.V12SavedDataForwardConverter.convertDataSources(V12SavedDataForwardConverter.java:501) > at com.businessobjects.reports.reportconverter.v12.V12SavedDataForwardConverter.convert(V12SavedDataForwardConverter.java:289) > at com.businessobjects.reports.reportconverter.v12.V12Converter.convertOldToNew(V12Converter.java:247) > at com.businessobjects.reports.reportconverter.v12.V12SaveLoader.load(V12SaveLoader.java:263) > at com.businessobjects.reports.reportconverter.v12.V12SaveLoader.load(V12SaveLoader.java:139) > at com.businessobjects.reports.loader.ReportLoader.loadHelper(ReportLoader.java:245) > at com.businessobjects.reports.loader.ReportLoader.load(ReportLoader.java:202) > at testapps.performance.TestCaseRunner.operationLoadReport(TestCaseRunner.java:633) > at testapps.performance.TestCases.testGotoFirstPage(TestCases.java:110) > at testapps.performance.TestCases.runTestCases(TestCases.java:335) > at testapps.performance.Runner.run(Runner.java:84) > at java.base/java.lang.Thread.run(Thread.java:1589) > ``` Maybe this test needs more code cache. > Crashes on ppcle (during build, no hs-err file remained): > > ``` > * For target jdk__optimize_image_exec: > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/g1BarrierSet.inline.hpp:39 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxppc64le/jdk-dev/src/hotspot/share/gc/g1/g1BarrierSet.inline.hpp:39), pid=27195, tid=27200 > # assert(oopDesc::is_oop(pre_val, true)) failed: Error > # > # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.openjdk.jdk-dev) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.openjdk.jdk-dev, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-ppc64le) > # Problematic frame: > # V [libjvm.so+0xc5532c] G1BarrierSet::enqueue_preloaded(oop)+0x28c > # > # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > # > ``` I think I might need help debugging this if it happens only on PPC. > Crash on x64 in vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java (hs-err attached): > > ``` > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxx86_64/jdk-dev/src/hotspot/share/prims/jvmtiExport.cpp:1700), pid=2633450, tid=2633476 > # assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking > # > ``` > > [hs_err_pid2633450.log](https://github.com/openjdk/jdk/files/9313935/hs_err_pid2633450.log) This one doesn't look like it should be related to my change, but I can have a look anyway. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From stuefe at openjdk.org Fri Aug 12 08:17:27 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 12 Aug 2022 08:17:27 GMT Subject: RFR: 8290025: Remove the Sweeper [v10] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 13:44:00 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Trigger GC from adapter blob allocations Hi Erik, I'll take a closer look next week, and by then we will have more test runs to get a better picture. Meanwhile, could you please merge the change to the current head? This would help us with our ideosyncratic CI. Thank you! ..Thomas ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Fri Aug 12 10:45:20 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 12 Aug 2022 10:45:20 GMT Subject: RFR: 8290025: Remove the Sweeper [v11] In-Reply-To: References: Message-ID: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Erik ?sterlund 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 'master' into 8290025_remove_sweeper - Trigger GC from adapter blob allocations - Zhengyu comments v1 - Redundant variable - Polish comment - Merge branch 'master' into 8290025_remove_sweeper - Removed more stale things - Remove incorrect comment - Feedback v2 - Feedback v1 - ... and 1 more: https://git.openjdk.org/jdk/compare/0c40128f...a06919b1 ------------- Changes: https://git.openjdk.org/jdk/pull/9741/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=10 Stats: 4118 lines in 188 files changed: 560 ins; 2991 del; 567 mod Patch: https://git.openjdk.org/jdk/pull/9741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9741/head:pull/9741 PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Fri Aug 12 10:45:21 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 12 Aug 2022 10:45:21 GMT Subject: RFR: 8290025: Remove the Sweeper [v10] In-Reply-To: References: Message-ID: <65HdN3ro2PsMM9ilGi5aJrxlsOUid7CbJlLF1FhJYNE=.e597499a-1a92-4721-b95d-d0268837971e@github.com> On Fri, 12 Aug 2022 08:13:54 GMT, Thomas Stuefe wrote: > Hi Erik, > > I'll take a closer look next week, and by then we will have more test runs to get a better picture. > > Meanwhile, could you please merge the change to the current head? This would help us with our ideosyncratic CI. Thank you! > > ..Thomas Thank you for having a look at this. I merged to the latest head, hope that helps! ------------- PR: https://git.openjdk.org/jdk/pull/9741 From rrich at openjdk.org Fri Aug 12 11:16:10 2022 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 12 Aug 2022 11:16:10 GMT Subject: RFR: 8291972: Fix double copy of arguments when thawing two interpreted frames In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 14:41:56 GMT, Patricio Chilano Mateo wrote: > When thawing two consecutive interpreted frames the current code makes room in the stack and copies the callee arguments twice, once in the caller and once in the callee. This duplication could use more stack space than the calculation made in prepare_thaw() for the maximum stack space that will be needed during thaw. If that's the case then we will hit an assert that we are writing pass the allowed limit. > Today we don't see this issue though because the only case where we could thaw two interpreter frames is the first time after a freeze. The thawed frames are always Continuation.yield and Continuation.yield0 and the extra used space is only 3 words(yield0's three arguments) which will never exceed the calculation made in prepare_thaw(). > The issue can be made visible when changing the number of frames we thaw when hitting a return barrier from 1 to 2 and running test Continuation/Basic.java. > > This patch fixes this by adjusting the calculated size of the callee frame in new_stack_frame() so that we use the space for the arguments already allocated by the caller. > > Tested the patch by changing the number of thaw frames from 1 to 2 and running all tests in jdk/internal/vm/Continuation/ and jdk/java/lang/Thread/virtual. Also run tiers1-3 in mach5 and loom-tiers1-4. > > Thanks, > Patricio This looks good! https://github.com/openjdk/jdk/pull/9850 duplicates this. It contains a reproducer test that asserts on aarch64. The test does not fail on x86_64 because padding for interpreter frames is added that is not needed on x86_64. Without that the test also asserts on x86_64 (see JDK-8292278). Thanks, Richard. ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.org/jdk/pull/9774 From coleenp at openjdk.org Fri Aug 12 12:37:21 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 12 Aug 2022 12:37:21 GMT Subject: RFR: 8292218: Convert PackageEntryTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 19:15:45 GMT, Coleen Phillimore wrote: >> This is the conversion of the PackageEntryTable, which is stored one per ClassLoaderData to ResourceHashtable. Much like the module table and uses the Module_lock. >> Tested with tier1-3 on linux, windows, mac. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix debug info and module name comparison. Thanks for reviewing this, Lois, Ioi and David. Yes, this conversion is a good illustration of how much nicer the ResourceHashtable is and our motivation. ------------- PR: https://git.openjdk.org/jdk/pull/9837 From coleenp at openjdk.org Fri Aug 12 12:41:20 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 12 Aug 2022 12:41:20 GMT Subject: Integrated: 8292218: Convert PackageEntryTable to ResourceHashtable In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 12:20:47 GMT, Coleen Phillimore wrote: > This is the conversion of the PackageEntryTable, which is stored one per ClassLoaderData to ResourceHashtable. Much like the module table and uses the Module_lock. > Tested with tier1-3 on linux, windows, mac. This pull request has now been integrated. Changeset: 9f8cc421 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/9f8cc4213561b28e24a84d836be6ce40f19f2c97 Stats: 300 lines in 8 files changed: 71 ins; 133 del; 96 mod 8292218: Convert PackageEntryTable to ResourceHashtable Reviewed-by: lfoltan, iklam, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/9837 From duke at openjdk.org Fri Aug 12 12:56:17 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 12 Aug 2022 12:56:17 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 04:57:37 GMT, David Holmes wrote: >Is this to allow use by different kinds of threads? Yes, to avoid having hard-coded branches for each case. If it's only one branch then I think it can be inlined and we can skip the template. This lets us move the methods out of the header file, which is also nice. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From duke at openjdk.org Fri Aug 12 13:05:10 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 12 Aug 2022 13:05:10 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: <77GANWr8ZxSXu8jig1h8CEZzj3rS52QHwJjW8z6QmNE=.d9c841a0-d2d7-4a0d-83e8-9ef394b167c9@github.com> References: <77GANWr8ZxSXu8jig1h8CEZzj3rS52QHwJjW8z6QmNE=.d9c841a0-d2d7-4a0d-83e8-9ef394b167c9@github.com> Message-ID: <2T6Tl0vduSD5YegenmwiXlnW9httMwfItO0GlKm2AxE=.9c8b5418-eab7-4095-9358-b2beff1f56dd@github.com> On Fri, 12 Aug 2022 05:27:24 GMT, David Holmes wrote: >Also did you establish this RW-lock will in fact be usable in this form for UL? I have rewritten the relevant code (`LogOutputList` class) using this RW-lock and it can run the VM in both async and synch mode. It passes all the tests for the class, and I've sent off a Mach5 job for it. I have read the code and it seems reasonable that this should work. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From coleenp at openjdk.org Fri Aug 12 13:14:51 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 12 Aug 2022 13:14:51 GMT Subject: RFR: 8292286: Convert PlaceholderTable to ResourceHashtable Message-ID: This change converts the PlaceholderTable to ResourceHashtable. It's much like the ResolutionErrorTable conversion. This change has been performance tested with the previous set of testing with no regression. It's also been tested tier1-3 and 4-7 with the other tables in my patch queue. ------------- Commit messages: - 8292286: Convert PlaceholderTable to ResourceHashtable Changes: https://git.openjdk.org/jdk/pull/9854/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9854&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292286 Stats: 287 lines in 6 files changed: 35 ins; 151 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/9854.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9854/head:pull/9854 PR: https://git.openjdk.org/jdk/pull/9854 From coleenp at openjdk.org Fri Aug 12 13:24:18 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 12 Aug 2022 13:24:18 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Message-ID: <39nneFOUe-wR-G9IjpEaDdLOI8ihO04p1Vv6deQDInc=.e00c9cf9-9bd5-4691-bb0a-2e6a1421c8a0@github.com> On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam wrote: > Fix two problems with synchronizer.hpp: > > - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! > - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. > > These headers are included much less after this PR (out of ~1000 hotspot .o files) > > > linkedlist.hpp 857 -> 101 > synchronizer.hpp 848 -> 122 > resourceHash.hpp 850 -> 270 Very nice. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/9849 From duke at openjdk.org Fri Aug 12 13:59:06 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Fri, 12 Aug 2022 13:59:06 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode Message-ID: This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: vptest xmm0, xmm1 jb if_true if_false: instead of: vptest xmm0, xmm1 setb r10 movzbl r10 testl r10 jne if_true if_false: The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: Before After Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. ------------- Commit messages: - copyright - fix condition - fix alltrue - change VectorTest to subclass Cmp - add test - fix aarch build - remove dst in x86.ad - fix aarch - fix aarch - unnecessary constraints - ... and 4 more: https://git.openjdk.org/jdk/compare/92d2982f...9667aa00 Changes: https://git.openjdk.org/jdk/pull/9855/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292289 Stats: 483 lines in 25 files changed: 201 ins; 131 del; 151 mod Patch: https://git.openjdk.org/jdk/pull/9855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9855/head:pull/9855 PR: https://git.openjdk.org/jdk/pull/9855 From dcubed at openjdk.org Fri Aug 12 15:30:18 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 12 Aug 2022 15:30:18 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Message-ID: On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam wrote: > Fix two problems with synchronizer.hpp: > > - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! > - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. > > These headers are included much less after this PR (out of ~1000 hotspot .o files) > > > linkedlist.hpp 857 -> 101 > synchronizer.hpp 848 -> 122 > resourceHash.hpp 850 -> 270 Looks great. I only posted a few nit comments. src/hotspot/share/gc/shenandoah/shenandoahPadding.hpp line 28: > 26: #define SHARE_GC_SHENANDOAH_SHENANDOAHPADDING_HPP > 27: > 28: #include "memory/padded.hpp" This one surprised me, but I'm guessing it was included indirectly from synchronizer.hpp via some frame header... src/hotspot/share/prims/jvmtiExport.hpp line 50: > 48: class JvmtiEnv; > 49: class JvmtiThreadState; > 50: class ThreadsList; Not in sorted order relative to OopStorage. Does it need to be? ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/9849 From pchilanomate at openjdk.org Fri Aug 12 15:32:17 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 12 Aug 2022 15:32:17 GMT Subject: RFR: 8291972: Fix double copy of arguments when thawing two interpreted frames In-Reply-To: References: Message-ID: <-NfATOKTFWEqME5iVr60rcm7tGayJoZ10wgTmbTmFgc=.e0757c93-2de5-4ea2-b36e-3694a44c99b7@github.com> On Wed, 10 Aug 2022 08:11:08 GMT, Ron Pressler wrote: >> When thawing two consecutive interpreted frames the current code makes room in the stack and copies the callee arguments twice, once in the caller and once in the callee. This duplication could use more stack space than the calculation made in prepare_thaw() for the maximum stack space that will be needed during thaw. If that's the case then we will hit an assert that we are writing pass the allowed limit. >> Today we don't see this issue though because the only case where we could thaw two interpreter frames is the first time after a freeze. The thawed frames are always Continuation.yield and Continuation.yield0 and the extra used space is only 3 words(yield0's three arguments) which will never exceed the calculation made in prepare_thaw(). >> The issue can be made visible when changing the number of frames we thaw when hitting a return barrier from 1 to 2 and running test Continuation/Basic.java. >> >> This patch fixes this by adjusting the calculated size of the callee frame in new_stack_frame() so that we use the space for the arguments already allocated by the caller. >> >> Tested the patch by changing the number of thaw frames from 1 to 2 and running all tests in jdk/internal/vm/Continuation/ and jdk/java/lang/Thread/virtual. Also run tiers1-3 in mach5 and loom-tiers1-4. >> >> Thanks, >> Patricio > > Looks fine to me. Thanks @pron, @robehn and @reinrich for the reviews! ------------- PR: https://git.openjdk.org/jdk/pull/9774 From pchilanomate at openjdk.org Fri Aug 12 15:32:19 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 12 Aug 2022 15:32:19 GMT Subject: RFR: 8291972: Fix double copy of arguments when thawing two interpreted frames In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 11:14:03 GMT, Richard Reingruber wrote: >> When thawing two consecutive interpreted frames the current code makes room in the stack and copies the callee arguments twice, once in the caller and once in the callee. This duplication could use more stack space than the calculation made in prepare_thaw() for the maximum stack space that will be needed during thaw. If that's the case then we will hit an assert that we are writing pass the allowed limit. >> Today we don't see this issue though because the only case where we could thaw two interpreter frames is the first time after a freeze. The thawed frames are always Continuation.yield and Continuation.yield0 and the extra used space is only 3 words(yield0's three arguments) which will never exceed the calculation made in prepare_thaw(). >> The issue can be made visible when changing the number of frames we thaw when hitting a return barrier from 1 to 2 and running test Continuation/Basic.java. >> >> This patch fixes this by adjusting the calculated size of the callee frame in new_stack_frame() so that we use the space for the arguments already allocated by the caller. >> >> Tested the patch by changing the number of thaw frames from 1 to 2 and running all tests in jdk/internal/vm/Continuation/ and jdk/java/lang/Thread/virtual. Also run tiers1-3 in mach5 and loom-tiers1-4. >> >> Thanks, >> Patricio > > This looks good! > > https://github.com/openjdk/jdk/pull/9850 duplicates this. It contains a reproducer test that asserts on aarch64. The test does not fail on x86_64 because padding for interpreter frames is added that is not needed on x86_64. Without that the test also asserts on x86_64 (see JDK-8292278). > > Thanks, Richard. @reinrich If you want to add that test I can add it here and list you as contributor or you can still push it in your PR once you are back. Let me know otherwise I will just integrate the fix. ------------- PR: https://git.openjdk.org/jdk/pull/9774 From rrich at openjdk.org Fri Aug 12 16:07:17 2022 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 12 Aug 2022 16:07:17 GMT Subject: RFR: 8291972: Fix double copy of arguments when thawing two interpreted frames In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 11:14:03 GMT, Richard Reingruber wrote: >> When thawing two consecutive interpreted frames the current code makes room in the stack and copies the callee arguments twice, once in the caller and once in the callee. This duplication could use more stack space than the calculation made in prepare_thaw() for the maximum stack space that will be needed during thaw. If that's the case then we will hit an assert that we are writing pass the allowed limit. >> Today we don't see this issue though because the only case where we could thaw two interpreter frames is the first time after a freeze. The thawed frames are always Continuation.yield and Continuation.yield0 and the extra used space is only 3 words(yield0's three arguments) which will never exceed the calculation made in prepare_thaw(). >> The issue can be made visible when changing the number of frames we thaw when hitting a return barrier from 1 to 2 and running test Continuation/Basic.java. >> >> This patch fixes this by adjusting the calculated size of the callee frame in new_stack_frame() so that we use the space for the arguments already allocated by the caller. >> >> Tested the patch by changing the number of thaw frames from 1 to 2 and running all tests in jdk/internal/vm/Continuation/ and jdk/java/lang/Thread/virtual. Also run tiers1-3 in mach5 and loom-tiers1-4. >> >> Thanks, >> Patricio > > This looks good! > > https://github.com/openjdk/jdk/pull/9850 duplicates this. It contains a reproducer test that asserts on aarch64. The test does not fail on x86_64 because padding for interpreter frames is added that is not needed on x86_64. Without that the test also asserts on x86_64 (see JDK-8292278). > > Thanks, Richard. > @reinrich If you want to add that test I can add it here and list you as contributor or you can still push it in your PR once you are back. Let me know otherwise I will just integrate the fix. Please add the test here if you think it is good. I'll close #9850 then. ------------- PR: https://git.openjdk.org/jdk/pull/9774 From pchilanomate at openjdk.org Fri Aug 12 16:33:38 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 12 Aug 2022 16:33:38 GMT Subject: RFR: 8291972: Fix double copy of arguments when thawing two interpreted frames [v2] In-Reply-To: References: Message-ID: > When thawing two consecutive interpreted frames the current code makes room in the stack and copies the callee arguments twice, once in the caller and once in the callee. This duplication could use more stack space than the calculation made in prepare_thaw() for the maximum stack space that will be needed during thaw. If that's the case then we will hit an assert that we are writing pass the allowed limit. > Today we don't see this issue though because the only case where we could thaw two interpreter frames is the first time after a freeze. The thawed frames are always Continuation.yield and Continuation.yield0 and the extra used space is only 3 words(yield0's three arguments) which will never exceed the calculation made in prepare_thaw(). > The issue can be made visible when changing the number of frames we thaw when hitting a return barrier from 1 to 2 and running test Continuation/Basic.java. > > This patch fixes this by adjusting the calculated size of the callee frame in new_stack_frame() so that we use the space for the arguments already allocated by the caller. > > Tested the patch by changing the number of thaw frames from 1 to 2 and running all tests in jdk/internal/vm/Continuation/ and jdk/java/lang/Thread/virtual. Also run tiers1-3 in mach5 and loom-tiers1-4. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Add Richard's reproducer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9774/files - new: https://git.openjdk.org/jdk/pull/9774/files/47cf7dce..b195999b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9774&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9774&range=00-01 Stats: 358 lines in 1 file changed: 358 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9774.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9774/head:pull/9774 PR: https://git.openjdk.org/jdk/pull/9774 From pchilanomate at openjdk.org Fri Aug 12 16:37:25 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 12 Aug 2022 16:37:25 GMT Subject: RFR: 8291972: Fix double copy of arguments when thawing two interpreted frames [v2] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 16:33:38 GMT, Patricio Chilano Mateo wrote: >> When thawing two consecutive interpreted frames the current code makes room in the stack and copies the callee arguments twice, once in the caller and once in the callee. This duplication could use more stack space than the calculation made in prepare_thaw() for the maximum stack space that will be needed during thaw. If that's the case then we will hit an assert that we are writing pass the allowed limit. >> Today we don't see this issue though because the only case where we could thaw two interpreter frames is the first time after a freeze. The thawed frames are always Continuation.yield and Continuation.yield0 and the extra used space is only 3 words(yield0's three arguments) which will never exceed the calculation made in prepare_thaw(). >> The issue can be made visible when changing the number of frames we thaw when hitting a return barrier from 1 to 2 and running test Continuation/Basic.java. >> >> This patch fixes this by adjusting the calculated size of the callee frame in new_stack_frame() so that we use the space for the arguments already allocated by the caller. >> >> Tested the patch by changing the number of thaw frames from 1 to 2 and running all tests in jdk/internal/vm/Continuation/ and jdk/java/lang/Thread/virtual. Also run tiers1-3 in mach5 and loom-tiers1-4. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Add Richard's reproducer Added Richard's test and run on both x64 and aarch64. Verified it fails on aarch64 without this fix and passes with it. ------------- PR: https://git.openjdk.org/jdk/pull/9774 From duke at openjdk.org Fri Aug 12 17:33:56 2022 From: duke at openjdk.org (Yi-Fan Tsai) Date: Fri, 12 Aug 2022 17:33:56 GMT Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods' heap [v6] In-Reply-To: References: Message-ID: > 8263377: Store method handle linkers in the 'non-nmethods' heap Yi-Fan Tsai 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' of https://github.com/yftsai/jdk into intrinsics_merge - Fix merge difference - Merge branch 'master' of https://github.com/yftsai/jdk into intrinsics - Merge branch 'master' of https://github.com/yftsai/jdk into intrinsics - Post dynamic_code_generate event when MH intrinsic generated - Remove dead codes remove unused argument of NativeJump::check_verified_entry_alignment remove unused argument of NativeJumip::patch_verified_entry remove dead codes in SharedRuntime::generate_method_handle_intrinsic_wrapper - Add PrintCodeCache support - Merge branch 'master' of https://github.com/yftsai/jdk into intrinsics - Merge branch 'master' of https://github.com/yftsai/jdk into intrinsics - Move to RuntimeBlob - ... and 11 more: https://git.openjdk.org/jdk/compare/0c40128f...f20fe0ff ------------- Changes: https://git.openjdk.org/jdk/pull/8760/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8760&range=05 Stats: 585 lines in 58 files changed: 279 ins; 173 del; 133 mod Patch: https://git.openjdk.org/jdk/pull/8760.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8760/head:pull/8760 PR: https://git.openjdk.org/jdk/pull/8760 From pchilanomate at openjdk.org Fri Aug 12 20:02:37 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 12 Aug 2022 20:02:37 GMT Subject: RFR: 8291972: Fix double copy of arguments when thawing two interpreted frames [v3] In-Reply-To: References: Message-ID: > When thawing two consecutive interpreted frames the current code makes room in the stack and copies the callee arguments twice, once in the caller and once in the callee. This duplication could use more stack space than the calculation made in prepare_thaw() for the maximum stack space that will be needed during thaw. If that's the case then we will hit an assert that we are writing pass the allowed limit. > Today we don't see this issue though because the only case where we could thaw two interpreter frames is the first time after a freeze. The thawed frames are always Continuation.yield and Continuation.yield0 and the extra used space is only 3 words(yield0's three arguments) which will never exceed the calculation made in prepare_thaw(). > The issue can be made visible when changing the number of frames we thaw when hitting a return barrier from 1 to 2 and running test Continuation/Basic.java. > > This patch fixes this by adjusting the calculated size of the callee frame in new_stack_frame() so that we use the space for the arguments already allocated by the caller. > > Tested the patch by changing the number of thaw frames from 1 to 2 and running all tests in jdk/internal/vm/Continuation/ and jdk/java/lang/Thread/virtual. Also run tiers1-3 in mach5 and loom-tiers1-4. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: add vm.continuations requirement to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9774/files - new: https://git.openjdk.org/jdk/pull/9774/files/b195999b..24903b01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9774&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9774&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9774.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9774/head:pull/9774 PR: https://git.openjdk.org/jdk/pull/9774 From dlong at openjdk.org Fri Aug 12 20:43:27 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 12 Aug 2022 20:43:27 GMT Subject: RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v8] In-Reply-To: <3Bei4QWe3XF1aS0bNKuHAXWkLTfXBf-Ug8OjzPPDEnw=.ce2e8c62-2313-47c0-84ca-fc456d0d2da8@github.com> References: <3Bei4QWe3XF1aS0bNKuHAXWkLTfXBf-Ug8OjzPPDEnw=.ce2e8c62-2313-47c0-84ca-fc456d0d2da8@github.com> Message-ID: On Tue, 9 Aug 2022 05:17:14 GMT, Axel Boldt-Christmas wrote: >> @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) >> >> Description from the original issue: >>> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >>> >>> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >>> >>> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. >> >> Testing: Tier 1-7 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Remove indentation Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9713 From dholmes at openjdk.org Fri Aug 12 21:11:13 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Aug 2022 21:11:13 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Message-ID: On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam wrote: > Fix two problems with synchronizer.hpp: > > - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! > - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. > > These headers are included much less after this PR (out of ~1000 hotspot .o files) > > > linkedlist.hpp 857 -> 101 > synchronizer.hpp 848 -> 122 > resourceHash.hpp 850 -> 270 Looks fine. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9849 From iklam at openjdk.org Fri Aug 12 21:45:23 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 12 Aug 2022 21:45:23 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp [v2] In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Message-ID: > Fix two problems with synchronizer.hpp: > > - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! > - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. > > These headers are included much less after this PR (out of ~1000 hotspot .o files) > > > linkedlist.hpp 857 -> 101 > synchronizer.hpp 848 -> 122 > resourceHash.hpp 850 -> 270 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @dcubed-ojdk review comments - reorder class forward declarations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9849/files - new: https://git.openjdk.org/jdk/pull/9849/files/9b372650..f2dfac39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9849&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9849&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9849.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9849/head:pull/9849 PR: https://git.openjdk.org/jdk/pull/9849 From duke at openjdk.org Fri Aug 12 22:21:14 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Fri, 12 Aug 2022 22:21:14 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v6] In-Reply-To: References: Message-ID: <9sVlylxE9ildyrm5c6h23OH4yW0KOITezSGDKIYaxpw=.1c687c5c-c664-465f-b3bd-3c9520eafc77@github.com> On Thu, 11 Aug 2022 21:19:07 GMT, Evgeny Astigeevich wrote: >> Runtime calls are calls of non-compiled methods. Non-compiled methods stay forever in CodeCache. If they are always within the branch range, they don't need trampolines. >> >> This PR adds `is_always_within_branch_range(Address entry)`. >> >> Results from DaCapo: the total number of eliminated trampolines per a benchmark run >> >> >> +----------+--------+ >> | avrora | 15491 | >> | batik | 75837 | >> | biojava | 13927 | >> | eclipse | 414143 | >> | fop | 119267 | >> | graphchi | 7665 | >> | jme | 8279 | >> | luindex | 56061 | >> | lusearch | 50277 | >> | pmd | 132719 | >> | sunflow | 10689 | >> | tomcat | 186967 | >> | xalan | 50349 | >> | zxing | 41497 | >> +----------+--------+ >> >> >> >> Testing: >> - `tier1`...`tier2`: Passed >> - `compiler/c2/aarch64/TestTrampoline.java`: Passed >> >> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Clarify non-compiled method in comments A failed test is `java/util/DoubleStreamSums/CompensatedSums.java` on windows-x64. I don't think my changes caused the failure. I found https://bugs.openjdk.org/browse/JDK-8288280. ------------- PR: https://git.openjdk.org/jdk/pull/8403 From kvn at openjdk.org Fri Aug 12 22:43:23 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 12 Aug 2022 22:43:23 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v6] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 21:19:07 GMT, Evgeny Astigeevich wrote: >> Runtime calls are calls of non-compiled methods. Non-compiled methods stay forever in CodeCache. If they are always within the branch range, they don't need trampolines. >> >> This PR adds `is_always_within_branch_range(Address entry)`. >> >> Results from DaCapo: the total number of eliminated trampolines per a benchmark run >> >> >> +----------+--------+ >> | avrora | 15491 | >> | batik | 75837 | >> | biojava | 13927 | >> | eclipse | 414143 | >> | fop | 119267 | >> | graphchi | 7665 | >> | jme | 8279 | >> | luindex | 56061 | >> | lusearch | 50277 | >> | pmd | 132719 | >> | sunflow | 10689 | >> | tomcat | 186967 | >> | xalan | 50349 | >> | zxing | 41497 | >> +----------+--------+ >> >> >> >> Testing: >> - `tier1`...`tier2`: Passed >> - `compiler/c2/aarch64/TestTrampoline.java`: Passed >> >> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Clarify non-compiled method in comments I will wait approval from Andrew before submitting my testing and approving. ------------- PR: https://git.openjdk.org/jdk/pull/8403 From iklam at openjdk.org Sun Aug 14 05:40:40 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 14 Aug 2022 05:40:40 GMT Subject: RFR: 8290981: Enable CDS for zero builds Message-ID: Enable CDS for zero builds. `java --version` is about 2x faster now. $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version 0.034645 +- 0.000044 seconds time elapsed ( +- 0.13% ) $ perf stat -r 40 ./images/jdk/bin/java -version 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% ) I also fixed a bug in Images.gmk that always wrote the default archive to $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to have a default CDS archive. ------------- Commit messages: - clean up C code - 8290981: Enable CDS for zero builds Changes: https://git.openjdk.org/jdk/pull/9869/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9869&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290981 Stats: 85 lines in 5 files changed: 32 ins; 25 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/9869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9869/head:pull/9869 PR: https://git.openjdk.org/jdk/pull/9869 From iklam at openjdk.org Sun Aug 14 05:52:01 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 14 Aug 2022 05:52:01 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: References: Message-ID: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> > Enable CDS for zero builds. `java --version` is about 2x faster now. > > > $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version > 0.034645 +- 0.000044 seconds time elapsed ( +- 0.13% ) > $ perf stat -r 40 ./images/jdk/bin/java -version > 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% ) > > I also fixed a bug in Images.gmk that always wrote the default archive to $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to have a default CDS archive. Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - create_cds_archive -> CreateCDSArchive - explicitly choose VM variant in create_cds_archive ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9869/files - new: https://git.openjdk.org/jdk/pull/9869/files/4d44c048..004c5038 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9869&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9869&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9869/head:pull/9869 PR: https://git.openjdk.org/jdk/pull/9869 From jwaters at openjdk.org Sun Aug 14 15:45:01 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 14 Aug 2022 15:45:01 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v12] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 18:02:18 GMT, Julian Waters wrote: >> JLI_ReportErrorMessageSys has a number of issues, as listed in the linked issue, since it's not widely used, it's easier to remove it and replace the areas it's called in with simpler calls to other error reporting functions: > > Julian Waters 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: > > Finalize Unix implementation, Windows to follow after Closing in favour of a newer rewrite ------------- PR: https://git.openjdk.org/jdk/pull/9793 From jwaters at openjdk.org Sun Aug 14 15:45:03 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 14 Aug 2022 15:45:03 GMT Subject: Withdrawn: 8292016: Rework JLI_ReportErrorMessageSys In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 04:23:14 GMT, Julian Waters wrote: > JLI_ReportErrorMessageSys has a number of issues, as listed in the linked issue, since it's not widely used, it's easier to remove it and replace the areas it's called in with simpler calls to other error reporting functions: This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9793 From jwaters at openjdk.org Sun Aug 14 17:01:31 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 14 Aug 2022 17:01:31 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys Message-ID: Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time (Clearing the error after the call, which is done in other areas of the JDK as well) Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. ------------- Commit messages: - Split Windows API errors out of JLI_ReportErrorMessageSys - Whitespace - Implement platform specific sections - Whitespace - Comment should mention usage risks - First rework Changes: https://git.openjdk.org/jdk/pull/9870/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292016 Stats: 108 lines in 5 files changed: 72 ins; 21 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Mon Aug 15 06:49:49 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 15 Aug 2022 06:49:49 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v2] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Backout of previous changes, just warn if both are present ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/08b70597..aec9e529 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=00-01 Stats: 85 lines in 2 files changed: 20 ins; 58 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Mon Aug 15 06:51:57 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 15 Aug 2022 06:51:57 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v3] In-Reply-To: References: Message-ID: <9pmQBmQVzaTOxmDQusJrCgTqJnxVRUJJZKm7uBk_5_s=.d8d28d1b-f00d-4e47-adef-b15ac0cb5205@github.com> > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Whitespaceee ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/aec9e529..a3879c2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From shade at openjdk.org Mon Aug 15 07:58:10 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Aug 2022 07:58:10 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> Message-ID: <5sG7YDdsl8g7JlNW0l40ez8OfiFudQDDSRuKZgodXhU=.cb42b06d-60a8-48c9-badd-b7d7e6a35e84@github.com> On Sun, 14 Aug 2022 05:52:01 GMT, Ioi Lam wrote: >> Enable CDS for zero builds. `java --version` is about 2x faster now. >> >> >> $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version >> 0.034645 +- 0.000044 seconds time elapsed ( +- 0.13% ) >> $ perf stat -r 40 ./images/jdk/bin/java -version >> 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% ) >> >> I also fixed a bug in Images.gmk that always wrote the default archive to $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to have a default CDS archive. > > Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: > > - create_cds_archive -> CreateCDSArchive > - explicitly choose VM variant in create_cds_archive Good stuff. Actually, let me see how easy it is to implement the `nofast_*` bytecodes in Zero, so we don't have to do the shared-code exceptions for it. ------------- PR: https://git.openjdk.org/jdk/pull/9869 From stuefe at openjdk.org Mon Aug 15 08:46:15 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 15 Aug 2022 08:46:15 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> Message-ID: <11Y0nfPYopf5JB15WwHHWtCWLzhSavtJUSYY9Ou_g1U=.a1264aef-c8d3-4e42-bd88-936c41901c9e@github.com> On Sun, 14 Aug 2022 05:52:01 GMT, Ioi Lam wrote: >> Enable CDS for zero builds. `java --version` is about 2x faster now. >> >> >> $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version >> 0.034645 +- 0.000044 seconds time elapsed ( +- 0.13% ) >> $ perf stat -r 40 ./images/jdk/bin/java -version >> 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% ) >> >> I also fixed a bug in Images.gmk that always wrote the default archive to $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to have a default CDS archive. > > Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: > > - create_cds_archive -> CreateCDSArchive > - explicitly choose VM variant in create_cds_archive Nice. I'll wait with the final review for what Alexey finds out. src/hotspot/cpu/zero/zeroInterpreter_zero.cpp line 40: > 38: #include "oops/oop.inline.hpp" > 39: #include "prims/jvmtiExport.hpp" > 40: #include "runtime/arguments.hpp" needs globals.hpp too ------------- PR: https://git.openjdk.org/jdk/pull/9869 From ayang at openjdk.org Mon Aug 15 09:23:15 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 15 Aug 2022 09:23:15 GMT Subject: RFR: 8292194: G1 nmethod entry barrier disarm value wraps around too early In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 14:53:06 GMT, Erik ?sterlund wrote: > The disarm value for G1 nmethod entry barriers assumes that a concurrent GC can be aborted at most once. However, it can happen many times. In order to avoid ABA issues in the nmethod entry barriers, the limit for wrapping around and reusing numbers needs to be higher. This patch changes that point to INT_MAX as there is little point in using lower values. Looks good. Though, it's unclear to me why the counter is signed in the first place. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.org/jdk/pull/9822 From stuefe at openjdk.org Mon Aug 15 09:43:22 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 15 Aug 2022 09:43:22 GMT Subject: RFR: JDK-8292351: tty should always live Message-ID: The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. tty should always be safe to write to, and that is trivial to do. ------------- Commit messages: - JDK-8292351-tty-should-always-live Changes: https://git.openjdk.org/jdk/pull/9874/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9874&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292351 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9874/head:pull/9874 PR: https://git.openjdk.org/jdk/pull/9874 From eosterlund at openjdk.org Mon Aug 15 09:56:25 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 15 Aug 2022 09:56:25 GMT Subject: RFR: 8292194: G1 nmethod entry barrier disarm value wraps around too early In-Reply-To: References: Message-ID: On Mon, 15 Aug 2022 09:21:09 GMT, Albert Mingkun Yang wrote: >> The disarm value for G1 nmethod entry barriers assumes that a concurrent GC can be aborted at most once. However, it can happen many times. In order to avoid ABA issues in the nmethod entry barriers, the limit for wrapping around and reusing numbers needs to be higher. This patch changes that point to INT_MAX as there is little point in using lower values. > > Looks good. Though, it's unclear to me why the counter is signed in the first place. Thanks for the review, @albertnetymk! ------------- PR: https://git.openjdk.org/jdk/pull/9822 From aboldtch at openjdk.org Mon Aug 15 09:56:41 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 15 Aug 2022 09:56:41 GMT Subject: Integrated: 8291718: Remove mark_for_deoptimization from klass unloading In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 14:30:07 GMT, Axel Boldt-Christmas wrote: > @stefank suggested creating a separate issue for this part of [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) > > Description from the original issue: >> The klass unloading code currently sets the mark for deoptimzation flag on nmethods that depend on the klass being unloaded. That however is all it does, there is no guarantee that those nmethods will become not entrant and make_deoptimized. The current implementation may if some future deoptimization happens to trigger see these marks as it scans the whole code cache, but it is never triggered from klass unloading. >> >> Me and [~eosterlund] discussed this and this behaviour seems like some leftover from earlier versions of klass unloading. There should be no reason to eliminate the nmethods that depend on unloaded klasses except to eliminate dead code. It is probably better to let other mechanisms decide if an nmethod with dead code should be deoptimized than the klass unloading. >> >> It might be a future improvement to have some stats which record that an nmethod had some dependency to an unloaded klass which might effect the heuristic for selecting what methods are deoptimized. > > Testing: Tier 1-7 This pull request has now been integrated. Changeset: fd4b2f28 Author: Axel Boldt-Christmas Committer: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/fd4b2f2868ac6eaf192b50db5c5adc76e0d54308 Stats: 57 lines in 18 files changed: 21 ins; 16 del; 20 mod 8291718: Remove mark_for_deoptimization from klass unloading Reviewed-by: eosterlund, dlong ------------- PR: https://git.openjdk.org/jdk/pull/9713 From duke at openjdk.org Mon Aug 15 10:28:19 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Mon, 15 Aug 2022 10:28:19 GMT Subject: RFR: 8292203: AArch64: Represent Registers as values [v2] In-Reply-To: References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> Message-ID: On Thu, 11 Aug 2022 21:24:37 GMT, Vladimir Ivanov wrote: >> (It's a PR dependent on #9815.) >> >> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation. >> >> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types. >> >> Proposed change hides pointer representation behind value class. >> >> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). >> >> Code quality improves: >> GCC: https://godbolt.org/z/r6G36facj >> Clang: https://godbolt.org/z/x5oPdYEPM >> >> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) >> >> Testing: hs-tier1 - hs-tier5 >> >> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' into rwrapper.aarch64 > - 8292203: AArch64: Represent Registers as values > - cleanups > - x86: Register class wrappers src/hotspot/cpu/aarch64/register_aarch64.hpp line 39: > 37: int _encoding; > 38: > 39: constexpr Register(int encoding, bool unused) : _encoding(encoding) {} Why do we need unused here? If the intention is to prevent implicit conversion from `int` to `Register` then you can mark the constructor as `explicit`. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9826 From duke at openjdk.org Mon Aug 15 10:39:16 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Mon, 15 Aug 2022 10:39:16 GMT Subject: RFR: 8292203: AArch64: Represent Registers as values [v2] In-Reply-To: References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> Message-ID: On Thu, 11 Aug 2022 21:24:37 GMT, Vladimir Ivanov wrote: >> (It's a PR dependent on #9815.) >> >> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation. >> >> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types. >> >> Proposed change hides pointer representation behind value class. >> >> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). >> >> Code quality improves: >> GCC: https://godbolt.org/z/r6G36facj >> Clang: https://godbolt.org/z/x5oPdYEPM >> >> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) >> >> Testing: hs-tier1 - hs-tier5 >> >> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' into rwrapper.aarch64 > - 8292203: AArch64: Represent Registers as values > - cleanups > - x86: Register class wrappers > Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). I don't really understand this part. Can we overload the `->` operator instead? I believe this works: Register* operator->() { return this; } ------------- PR: https://git.openjdk.org/jdk/pull/9826 From aph at openjdk.org Mon Aug 15 10:44:25 2022 From: aph at openjdk.org (Andrew Haley) Date: Mon, 15 Aug 2022 10:44:25 GMT Subject: RFR: 8292203: AArch64: Represent Registers as values [v2] In-Reply-To: References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> Message-ID: On Mon, 15 Aug 2022 10:37:00 GMT, Quan Anh Mai wrote: > > Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). > > I don't really understand this part. Can we overload the `->` operator instead? I believe this works: > > ``` > Register* operator->() { > return this; > } I tried something like that before, and got poor code quality. ------------- PR: https://git.openjdk.org/jdk/pull/9826 From shade at openjdk.org Mon Aug 15 10:59:20 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Aug 2022 10:59:20 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: <11Y0nfPYopf5JB15WwHHWtCWLzhSavtJUSYY9Ou_g1U=.a1264aef-c8d3-4e42-bd88-936c41901c9e@github.com> References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> <11Y0nfPYopf5JB15WwHHWtCWLzhSavtJUSYY9Ou_g1U=.a1264aef-c8d3-4e42-bd88-936c41901c9e@github.com> Message-ID: On Sun, 14 Aug 2022 06:07:33 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: >> >> - create_cds_archive -> CreateCDSArchive >> - explicitly choose VM variant in create_cds_archive > > src/hotspot/cpu/zero/zeroInterpreter_zero.cpp line 40: > >> 38: #include "oops/oop.inline.hpp" >> 39: #include "prims/jvmtiExport.hpp" >> 40: #include "runtime/arguments.hpp" > > needs globals.hpp too Why? `arguments.hpp` transitively includes it. ------------- PR: https://git.openjdk.org/jdk/pull/9869 From shade at openjdk.org Mon Aug 15 11:16:24 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Aug 2022 11:16:24 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: <5sG7YDdsl8g7JlNW0l40ez8OfiFudQDDSRuKZgodXhU=.cb42b06d-60a8-48c9-badd-b7d7e6a35e84@github.com> References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> <5sG7YDdsl8g7JlNW0l40ez8OfiFudQDDSRuKZgodXhU=.cb42b06d-60a8-48c9-badd-b7d7e6a35e84@github.com> Message-ID: On Mon, 15 Aug 2022 07:54:18 GMT, Aleksey Shipilev wrote: > Good stuff. Actually, let me see how easy it is to implement the `nofast_*` bytecodes in Zero, so we don't have to do the shared-code exceptions for it. That took some debugging :) But here it is, applied on top of your PR: https://cr.openjdk.java.net/~shade/8290981/zero-cds-nofast-1.patch -- builds Linux x86_64 Zero fine, this includes using the Zero VM to compile parts of JDK. I can do more testing later, we should at least test it bootcycles well. ------------- PR: https://git.openjdk.org/jdk/pull/9869 From duke at openjdk.org Mon Aug 15 11:38:12 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Mon, 15 Aug 2022 11:38:12 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v6] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 22:41:18 GMT, Vladimir Kozlov wrote: > I will wait approval from Andrew before submitting my testing and approving. Hi @theRealAph, Do you have any comments? Thanks, Evgeny ------------- PR: https://git.openjdk.org/jdk/pull/8403 From jwaters at openjdk.org Mon Aug 15 12:04:23 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 15 Aug 2022 12:04:23 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v4] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Compile error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/a3879c2d..a8dea8a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From erikj at openjdk.org Mon Aug 15 12:46:13 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 15 Aug 2022 12:46:13 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> Message-ID: On Sun, 14 Aug 2022 05:52:01 GMT, Ioi Lam wrote: >> Enable CDS for zero builds. `java --version` is about 2x faster now. >> >> >> $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version >> 0.034645 +- 0.000044 seconds time elapsed ( +- 0.13% ) >> $ perf stat -r 40 ./images/jdk/bin/java -version >> 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% ) >> >> I also fixed a bug in Images.gmk that always wrote the default archive to $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to have a default CDS archive. > > Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: > > - create_cds_archive -> CreateCDSArchive > - explicitly choose VM variant in create_cds_archive Build changes look good. make/Images.gmk line 144: > 142: > 143: $$(eval $$(call SetupExecute, $1_$2_gen_cds_archive_jre, \ > 144: WARN := Creating CDS$$($1_$2_DUMP_TYPE) archive for jre image, \ Perhaps include the variant name in the log message here, as is done above for the jdk image? ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/9869 From dholmes at openjdk.org Mon Aug 15 13:27:13 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Aug 2022 13:27:13 GMT Subject: RFR: JDK-8292351: tty should always live In-Reply-To: References: Message-ID: On Mon, 15 Aug 2022 09:25:17 GMT, Thomas Stuefe wrote: > The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. > > This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. > > tty should always be safe to write to, and that is trivial to do. So effectively this just introduces an alternate tty device for pre-init and post-shutdown. But if the tty is not stdout then you are now forcing use of stdout in an environment where someone may have taken steps to ensure stdout is not in fact used. Is that real concern? I don't know. We jump through a number of hoops in terms of controlling VM output and it seems somewhat excessive to me, but I have to assume there were valid reasons for the level of complexity that it exists. Need to think more about this ... ------------- PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Mon Aug 15 14:22:35 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 15 Aug 2022 14:22:35 GMT Subject: RFR: JDK-8292351: tty should always live In-Reply-To: References: Message-ID: On Mon, 15 Aug 2022 13:23:58 GMT, David Holmes wrote: > So effectively this just introduces an alternate tty device for pre-init and post-shutdown. But if the tty is not stdout then you are now forcing use of stdout in an environment where someone may have taken steps to ensure stdout is not in fact used. I don't force using stdout. I prevent the VM from crashing. Before my patch, the VM would have crashed. Now it prints the message it wanted to print, to stdout, which is in 99 % of all cases what users expect anyway since it's the default behavior. > Is that real concern? Yes. So much that in our downstream VMs I have stopped using tty and instead use fdStream(1) or (2) as much as possible, unless I am absolutely sure that tty is valid whenever my code runs. But this is a style I cannot use in OpenJDK since the rule is "use tty". > I don't know. We jump through a number of hoops in terms of controlling VM output and it seems somewhat excessive to me, but I have to assume there were valid reasons for the level of complexity that it exists. I don't particularly like defaultStream, especially its XML mode, and would be happy if it were simplified. > > Need to think more about this ... ------------- PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Mon Aug 15 14:25:14 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 15 Aug 2022 14:25:14 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> <11Y0nfPYopf5JB15WwHHWtCWLzhSavtJUSYY9Ou_g1U=.a1264aef-c8d3-4e42-bd88-936c41901c9e@github.com> Message-ID: On Mon, 15 Aug 2022 10:57:04 GMT, Aleksey Shipilev wrote: > Why? `arguments.hpp` transitively includes it. I thought the rule is not to rely on transitive includes. Unless it is an explicit umbrella header. If you need it, include it - that way if someone changes the include tree, we minimize the possibility of seemingly unrelated build errors. ------------- PR: https://git.openjdk.org/jdk/pull/9869 From shade at openjdk.org Mon Aug 15 14:30:19 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Aug 2022 14:30:19 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> <11Y0nfPYopf5JB15WwHHWtCWLzhSavtJUSYY9Ou_g1U=.a1264aef-c8d3-4e42-bd88-936c41901c9e@github.com> Message-ID: On Mon, 15 Aug 2022 14:21:18 GMT, Thomas Stuefe wrote: >> Why? `arguments.hpp` transitively includes it. > >> Why? `arguments.hpp` transitively includes it. > > I thought the rule is not to rely on transitive includes. Unless it is an explicit umbrella header. If you need it, include it - that way if someone changes the include tree, we minimize the possibility of seemingly unrelated build errors. Ah, you mean because we use `RewriteBytecodes`, I see. Yes, we need the explicit header. My additional patch uses `UseSharedSpaces`, so it needs the additional include too. ------------- PR: https://git.openjdk.org/jdk/pull/9869 From duke at openjdk.org Mon Aug 15 14:33:27 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Mon, 15 Aug 2022 14:33:27 GMT Subject: RFR: 8290025: Remove the Sweeper [v10] In-Reply-To: <65HdN3ro2PsMM9ilGi5aJrxlsOUid7CbJlLF1FhJYNE=.e597499a-1a92-4721-b95d-d0268837971e@github.com> References: <65HdN3ro2PsMM9ilGi5aJrxlsOUid7CbJlLF1FhJYNE=.e597499a-1a92-4721-b95d-d0268837971e@github.com> Message-ID: On Fri, 12 Aug 2022 10:42:11 GMT, Erik ?sterlund wrote: >> Hi Erik, >> >> I'll take a closer look next week, and by then we will have more test runs to get a better picture. >> >> Meanwhile, could you please merge the change to the current head? This would help us with our ideosyncratic CI. Thank you! >> >> ..Thomas > >> Hi Erik, >> >> I'll take a closer look next week, and by then we will have more test runs to get a better picture. >> >> Meanwhile, could you please merge the change to the current head? This would help us with our ideosyncratic CI. Thank you! >> >> ..Thomas > > Thank you for having a look at this. I merged to the latest head, hope that helps! Hi Erik (@fisk), We have a real-life workload with 20k - 50k compiled methods. I'd like to test the patch with it. The workload uses jdk17. How difficult is to port the patch to 17? ------------- PR: https://git.openjdk.org/jdk/pull/9741 From stuefe at openjdk.org Mon Aug 15 14:34:18 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 15 Aug 2022 14:34:18 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> <11Y0nfPYopf5JB15WwHHWtCWLzhSavtJUSYY9Ou_g1U=.a1264aef-c8d3-4e42-bd88-936c41901c9e@github.com> Message-ID: On Mon, 15 Aug 2022 14:26:38 GMT, Aleksey Shipilev wrote: >>> Why? `arguments.hpp` transitively includes it. >> >> I thought the rule is not to rely on transitive includes. Unless it is an explicit umbrella header. If you need it, include it - that way if someone changes the include tree, we minimize the possibility of seemingly unrelated build errors. > > Ah, you mean because we use `RewriteBytecodes`, I see. Yes, we need the explicit header. My additional patch uses `UseSharedSpaces`, so it needs the additional include too. Yes, RewriteBytecode. Sorry, should have said. ------------- PR: https://git.openjdk.org/jdk/pull/9869 From pchilanomate at openjdk.org Mon Aug 15 14:38:25 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 15 Aug 2022 14:38:25 GMT Subject: Integrated: 8291972: Fix double copy of arguments when thawing two interpreted frames In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 14:41:56 GMT, Patricio Chilano Mateo wrote: > When thawing two consecutive interpreted frames the current code makes room in the stack and copies the callee arguments twice, once in the caller and once in the callee. This duplication could use more stack space than the calculation made in prepare_thaw() for the maximum stack space that will be needed during thaw. If that's the case then we will hit an assert that we are writing pass the allowed limit. > Today we don't see this issue though because the only case where we could thaw two interpreter frames is the first time after a freeze. The thawed frames are always Continuation.yield and Continuation.yield0 and the extra used space is only 3 words(yield0's three arguments) which will never exceed the calculation made in prepare_thaw(). > The issue can be made visible when changing the number of frames we thaw when hitting a return barrier from 1 to 2 and running test Continuation/Basic.java. > > This patch fixes this by adjusting the calculated size of the callee frame in new_stack_frame() so that we use the space for the arguments already allocated by the caller. > > Tested the patch by changing the number of thaw frames from 1 to 2 and running all tests in jdk/internal/vm/Continuation/ and jdk/java/lang/Thread/virtual. Also run tiers1-3 in mach5 and loom-tiers1-4. > > Thanks, > Patricio This pull request has now been integrated. Changeset: dd2034b0 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/dd2034b00725f0fc777c1706b1db898475e89c5c Stats: 365 lines in 3 files changed: 363 ins; 0 del; 2 mod 8291972: Fix double copy of arguments when thawing two interpreted frames Co-authored-by: Richard Reingruber Co-authored-by: Patricio Chilano Mateo Reviewed-by: rpressler, rehn, rrich ------------- PR: https://git.openjdk.org/jdk/pull/9774 From duke at openjdk.org Mon Aug 15 15:15:25 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 15 Aug 2022 15:15:25 GMT Subject: RFR: JDK-8292351: tty should always live In-Reply-To: References: Message-ID: On Mon, 15 Aug 2022 09:25:17 GMT, Thomas Stuefe wrote: > The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. > > This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. > > tty should always be safe to write to, and that is trivial to do. The goal should be to replace tty with UL in as many cases as possible. So to me this change is great, because in the far future we can reduce tty to only this in those rare cases where UL isn't available yet. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From aboldtch at openjdk.org Mon Aug 15 15:20:04 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 15 Aug 2022 15:20:04 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v4] In-Reply-To: References: Message-ID: > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Rename deoptimize_done enum value - Add missing code from list revert - Initial draft new terminology - Make _context_active atomic - Missed merge changes - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Merge branch 'JDK-8291718' into JDK-8291237 - Remove indentation - Fix for shenandoah - ... and 13 more: https://git.openjdk.org/jdk/compare/fd4b2f28...2be7b152 ------------- Changes: https://git.openjdk.org/jdk/pull/9655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=03 Stats: 685 lines in 27 files changed: 283 ins; 284 del; 118 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From hseigel at openjdk.org Mon Aug 15 15:30:12 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 15 Aug 2022 15:30:12 GMT Subject: RFR: 8292286: Convert PlaceholderTable to ResourceHashtable In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 13:07:03 GMT, Coleen Phillimore wrote: > This change converts the PlaceholderTable to ResourceHashtable. It's much like the ResolutionErrorTable conversion. This change has been performance tested with the previous set of testing with no regression. It's also been tested tier1-3 and 4-7 with the other tables in my patch queue. src/hotspot/share/classfile/placeholders.hpp line 111: > 109: _supername = supername; > 110: if (_supername != nullptr) _supername->increment_refcount(); > 111: } Could you use maybe_increment_refcount() instead of checking for NULL in the above code? ------------- PR: https://git.openjdk.org/jdk/pull/9854 From coleenp at openjdk.org Mon Aug 15 15:59:31 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Aug 2022 15:59:31 GMT Subject: RFR: 8292286: Convert PlaceholderTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: <0hR7rqCF34X1NtlBJHcXndrmEgy8lxCiTfo3D-cqMpo=.ecfcc7cf-824f-49cf-b62e-0b48de32a33e@github.com> > This change converts the PlaceholderTable to ResourceHashtable. It's much like the ResolutionErrorTable conversion. This change has been performance tested with the previous set of testing with no regression. It's also been tested tier1-3 and 4-7 with the other tables in my patch queue. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Use Symbol::maybe increment or decrement refcount. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9854/files - new: https://git.openjdk.org/jdk/pull/9854/files/76db3258..4a0cd646 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9854&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9854&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9854.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9854/head:pull/9854 PR: https://git.openjdk.org/jdk/pull/9854 From coleenp at openjdk.org Mon Aug 15 15:59:33 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Aug 2022 15:59:33 GMT Subject: RFR: 8292286: Convert PlaceholderTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: <5K70Eudwnipm65xmWns1fdy4-uE2tVLYk5EbQpta_j8=.d3bdf0f1-38c7-4098-8a5c-4e3d3c92d3a0@github.com> On Mon, 15 Aug 2022 15:26:44 GMT, Harold Seigel wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Symbol::maybe increment or decrement refcount. > > src/hotspot/share/classfile/placeholders.hpp line 111: > >> 109: _supername = supername; >> 110: if (_supername != nullptr) _supername->increment_refcount(); >> 111: } > > Could you use maybe_increment_refcount() instead of checking for NULL in the above code? Yes, I fixed it to use the maybe version instead. ------------- PR: https://git.openjdk.org/jdk/pull/9854 From hseigel at openjdk.org Mon Aug 15 17:14:12 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 15 Aug 2022 17:14:12 GMT Subject: RFR: 8292286: Convert PlaceholderTable to ResourceHashtable [v2] In-Reply-To: <0hR7rqCF34X1NtlBJHcXndrmEgy8lxCiTfo3D-cqMpo=.ecfcc7cf-824f-49cf-b62e-0b48de32a33e@github.com> References: <0hR7rqCF34X1NtlBJHcXndrmEgy8lxCiTfo3D-cqMpo=.ecfcc7cf-824f-49cf-b62e-0b48de32a33e@github.com> Message-ID: On Mon, 15 Aug 2022 15:59:31 GMT, Coleen Phillimore wrote: >> This change converts the PlaceholderTable to ResourceHashtable. It's much like the ResolutionErrorTable conversion. This change has been performance tested with the previous set of testing with no regression. It's also been tested tier1-3 and 4-7 with the other tables in my patch queue. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use Symbol::maybe increment or decrement refcount. Changes look good! Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.org/jdk/pull/9854 From shade at openjdk.org Mon Aug 15 17:22:15 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Aug 2022 17:22:15 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> <5sG7YDdsl8g7JlNW0l40ez8OfiFudQDDSRuKZgodXhU=.cb42b06d-60a8-48c9-badd-b7d7e6a35e84@github.com> Message-ID: On Mon, 15 Aug 2022 11:12:49 GMT, Aleksey Shipilev wrote: > > Good stuff. Actually, let me see how easy it is to implement the `nofast_*` bytecodes in Zero, so we don't have to do the shared-code exceptions for it. > > That took some debugging :) But here it is, applied on top of your PR: https://cr.openjdk.java.net/~shade/8290981/zero-cds-nofast-1.patch -- builds Linux x86_64 Zero fine, this includes using the Zero VM to compile parts of JDK. I can do more testing later, we should at least test it bootcycles well. Passes Linux x86_64 fastdebug Zero `make bootcycle-images` too. ------------- PR: https://git.openjdk.org/jdk/pull/9869 From iklam at openjdk.org Mon Aug 15 17:37:23 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 15 Aug 2022 17:37:23 GMT Subject: RFR: 8292286: Convert PlaceholderTable to ResourceHashtable [v2] In-Reply-To: <0hR7rqCF34X1NtlBJHcXndrmEgy8lxCiTfo3D-cqMpo=.ecfcc7cf-824f-49cf-b62e-0b48de32a33e@github.com> References: <0hR7rqCF34X1NtlBJHcXndrmEgy8lxCiTfo3D-cqMpo=.ecfcc7cf-824f-49cf-b62e-0b48de32a33e@github.com> Message-ID: On Mon, 15 Aug 2022 15:59:31 GMT, Coleen Phillimore wrote: >> This change converts the PlaceholderTable to ResourceHashtable. It's much like the ResolutionErrorTable conversion. This change has been performance tested with the previous set of testing with no regression. It's also been tested tier1-3 and 4-7 with the other tables in my patch queue. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use Symbol::maybe increment or decrement refcount. Changes requested by iklam (Reviewer). src/hotspot/share/classfile/placeholders.cpp line 36: > 34: #include "utilities/resourceHash.hpp" > 35: > 36: class PlaceholderKey : public StackObj { Since the PlaceholderKey is stored inside the _placeholders table, I think it shouldn't be declared as StackObj. src/hotspot/share/classfile/placeholders.cpp line 46: > 44: } > 45: static unsigned hash(PlaceholderKey const& k) { > 46: return (unsigned) k._name->identity_hash(); Should this be XORed with _loader_data? ------------- PR: https://git.openjdk.org/jdk/pull/9854 From jwaters at openjdk.org Mon Aug 15 17:54:20 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 15 Aug 2022 17:54:20 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v5] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Revert accidental removal of memory release ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/a8dea8a2..04909015 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=03-04 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From svkamath at openjdk.org Mon Aug 15 17:55:13 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Mon, 15 Aug 2022 17:55:13 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 03:12:10 GMT, AJ Ferguson wrote: > Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. @AJ-Ferguson, will take a look at the PR. Thank you. ------------- PR: https://git.openjdk.org/jdk/pull/9635 From jwaters at openjdk.org Mon Aug 15 18:09:36 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 15 Aug 2022 18:09:36 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v6] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Refactor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/04909015..82419b64 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From coleenp at openjdk.org Mon Aug 15 18:19:41 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Aug 2022 18:19:41 GMT Subject: RFR: 8292286: Convert PlaceholderTable to ResourceHashtable [v3] In-Reply-To: References: Message-ID: > This change converts the PlaceholderTable to ResourceHashtable. It's much like the ResolutionErrorTable conversion. This change has been performance tested with the previous set of testing with no regression. It's also been tested tier1-3 and 4-7 with the other tables in my patch queue. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Ioi comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9854/files - new: https://git.openjdk.org/jdk/pull/9854/files/4a0cd646..0e91307f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9854&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9854&range=01-02 Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9854.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9854/head:pull/9854 PR: https://git.openjdk.org/jdk/pull/9854 From coleenp at openjdk.org Mon Aug 15 18:19:42 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Aug 2022 18:19:42 GMT Subject: RFR: 8292286: Convert PlaceholderTable to ResourceHashtable [v2] In-Reply-To: References: <0hR7rqCF34X1NtlBJHcXndrmEgy8lxCiTfo3D-cqMpo=.ecfcc7cf-824f-49cf-b62e-0b48de32a33e@github.com> Message-ID: <-ymwFT9LvL9XcDI0DT4rO1XjJPz5COFLtDfmhRuFlhM=.d37cd47c-9deb-45ba-8801-ae1d26453ac8@github.com> On Mon, 15 Aug 2022 17:14:22 GMT, Ioi Lam wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Symbol::maybe increment or decrement refcount. > > src/hotspot/share/classfile/placeholders.cpp line 36: > >> 34: #include "utilities/resourceHash.hpp" >> 35: >> 36: class PlaceholderKey : public StackObj { > > Since the PlaceholderKey is stored inside the _placeholders table, I think it shouldn't be declared as StackObj. Ok, fixed. > src/hotspot/share/classfile/placeholders.cpp line 46: > >> 44: } >> 45: static unsigned hash(PlaceholderKey const& k) { >> 46: return (unsigned) k._name->identity_hash(); > > Should this be XORed with _loader_data? It wasn't before because it shared a hashcode with Dictionary, but now it doesn't anymore so I xor'ed it now. ------------- PR: https://git.openjdk.org/jdk/pull/9854 From coleenp at openjdk.org Mon Aug 15 18:19:42 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Aug 2022 18:19:42 GMT Subject: RFR: 8292286: Convert PlaceholderTable to ResourceHashtable [v2] In-Reply-To: <0hR7rqCF34X1NtlBJHcXndrmEgy8lxCiTfo3D-cqMpo=.ecfcc7cf-824f-49cf-b62e-0b48de32a33e@github.com> References: <0hR7rqCF34X1NtlBJHcXndrmEgy8lxCiTfo3D-cqMpo=.ecfcc7cf-824f-49cf-b62e-0b48de32a33e@github.com> Message-ID: On Mon, 15 Aug 2022 15:59:31 GMT, Coleen Phillimore wrote: >> This change converts the PlaceholderTable to ResourceHashtable. It's much like the ResolutionErrorTable conversion. This change has been performance tested with the previous set of testing with no regression. It's also been tested tier1-3 and 4-7 with the other tables in my patch queue. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use Symbol::maybe increment or decrement refcount. src/hotspot/share/classfile/placeholders.cpp line 222: > 220: // Decrement refcount in key. > 221: class_name->decrement_refcount(); > 222: _placeholders.remove(key); This was in the wrong order. We should decrement the refcount after removing the entry. ------------- PR: https://git.openjdk.org/jdk/pull/9854 From iklam at openjdk.org Mon Aug 15 18:38:35 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 15 Aug 2022 18:38:35 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v3] In-Reply-To: References: Message-ID: > Enable CDS for zero builds. `java --version` is about 2x faster now. > > > $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version > 0.034645 +- 0.000044 seconds time elapsed ( +- 0.13% ) > $ perf stat -r 40 ./images/jdk/bin/java -version > 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% ) > > I also fixed a bug in Images.gmk that always wrote the default archive to $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to have a default CDS archive. 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: - @erikj79 comments; also fixed CDS test cases for zero - Merge branch 'master' into 8290981-enable-cds-for-zero - imported contribution by @shipilev - https://cr.openjdk.java.net/~shade/8290981/zero-cds-nofast-1.patch - create_cds_archive -> CreateCDSArchive - explicitly choose VM variant in create_cds_archive - clean up C code - 8290981: Enable CDS for zero builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9869/files - new: https://git.openjdk.org/jdk/pull/9869/files/004c5038..2716becb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9869&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9869&range=01-02 Stats: 20828 lines in 932 files changed: 11978 ins; 5521 del; 3329 mod Patch: https://git.openjdk.org/jdk/pull/9869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9869/head:pull/9869 PR: https://git.openjdk.org/jdk/pull/9869 From iklam at openjdk.org Mon Aug 15 18:41:03 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 15 Aug 2022 18:41:03 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> <5sG7YDdsl8g7JlNW0l40ez8OfiFudQDDSRuKZgodXhU=.cb42b06d-60a8-48c9-badd-b7d7e6a35e84@github.com> Message-ID: On Mon, 15 Aug 2022 17:18:54 GMT, Aleksey Shipilev wrote: >>> Good stuff. Actually, let me see how easy it is to implement the `nofast_*` bytecodes in Zero, so we don't have to do the shared-code exceptions for it. >> >> That took some debugging :) But here it is, applied on top of your PR: https://cr.openjdk.java.net/~shade/8290981/zero-cds-nofast-1.patch -- builds Linux x86_64 Zero fine, this includes using the Zero VM to compile parts of JDK. I can do more testing later, we should at least test it bootcycles well. > >> > Good stuff. Actually, let me see how easy it is to implement the `nofast_*` bytecodes in Zero, so we don't have to do the shared-code exceptions for it. >> >> That took some debugging :) But here it is, applied on top of your PR: https://cr.openjdk.java.net/~shade/8290981/zero-cds-nofast-1.patch -- builds Linux x86_64 Zero fine, this includes using the Zero VM to compile parts of JDK. I can do more testing later, we should at least test it bootcycles well. > > Passes Linux x86_64 fastdebug Zero `make bootcycle-images` too. @shipilev thanks for sending the patch. I've integrated it. I ran all the tests under test/hotspot/jtreg/runtime/cds/appcds. They all passed after I fixed two of the test cases. Do you know how much testing is done by the community with zero? We don't test it that much in our pipeline. ------------- PR: https://git.openjdk.org/jdk/pull/9869 From iklam at openjdk.org Mon Aug 15 18:44:28 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 15 Aug 2022 18:44:28 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v4] In-Reply-To: References: Message-ID: > Enable CDS for zero builds. `java --version` is about 2x faster now. > > > $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version > 0.034645 +- 0.000044 seconds time elapsed ( +- 0.13% ) > $ perf stat -r 40 ./images/jdk/bin/java -version > 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% ) > > I also fixed a bug in Images.gmk that always wrote the default archive to $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to have a default CDS archive. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed copyright and whitespaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9869/files - new: https://git.openjdk.org/jdk/pull/9869/files/2716becb..94fd577e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9869&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9869&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9869/head:pull/9869 PR: https://git.openjdk.org/jdk/pull/9869 From jwaters at openjdk.org Mon Aug 15 18:47:29 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 15 Aug 2022 18:47:29 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v7] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: errno should be checked for a 0 status code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/82419b64..d4204bfa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=05-06 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Mon Aug 15 19:00:24 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 15 Aug 2022 19:00:24 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v8] In-Reply-To: References: Message-ID: <_V16sQnxJQ6HfU8irijvGeUY8WVJuToCEC30rSs525o=.b43585dd-7174-4994-b56d-f6d5bf27fb66@github.com> > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Tabs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/d4204bfa..a1fc9cd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From iklam at openjdk.org Mon Aug 15 20:21:17 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 15 Aug 2022 20:21:17 GMT Subject: RFR: 8292286: Convert PlaceholderTable to ResourceHashtable [v3] In-Reply-To: References: Message-ID: On Mon, 15 Aug 2022 18:19:41 GMT, Coleen Phillimore wrote: >> This change converts the PlaceholderTable to ResourceHashtable. It's much like the ResolutionErrorTable conversion. This change has been performance tested with the previous set of testing with no regression. It's also been tested tier1-3 and 4-7 with the other tables in my patch queue. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Ioi comments. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/9854 From eosterlund at openjdk.org Mon Aug 15 20:46:11 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 15 Aug 2022 20:46:11 GMT Subject: RFR: 8290025: Remove the Sweeper [v10] In-Reply-To: <65HdN3ro2PsMM9ilGi5aJrxlsOUid7CbJlLF1FhJYNE=.e597499a-1a92-4721-b95d-d0268837971e@github.com> References: <65HdN3ro2PsMM9ilGi5aJrxlsOUid7CbJlLF1FhJYNE=.e597499a-1a92-4721-b95d-d0268837971e@github.com> Message-ID: <_oY0vCTPn4WV-d3qvXzoJOoUPFJBCRd_XuXdl7jKC-Q=.d5f8e298-a098-4eb7-be96-57c8f21f2cb8@github.com> On Fri, 12 Aug 2022 10:42:11 GMT, Erik ?sterlund wrote: >> Hi Erik, >> >> I'll take a closer look next week, and by then we will have more test runs to get a better picture. >> >> Meanwhile, could you please merge the change to the current head? This would help us with our ideosyncratic CI. Thank you! >> >> ..Thomas > >> Hi Erik, >> >> I'll take a closer look next week, and by then we will have more test runs to get a better picture. >> >> Meanwhile, could you please merge the change to the current head? This would help us with our ideosyncratic CI. Thank you! >> >> ..Thomas > > Thank you for having a look at this. I merged to the latest head, hope that helps! > Hi Erik (@fisk), > > We have a real-life workload with 20k - 50k compiled methods. I'd like to test the patch with it. The workload uses jdk17. > > How difficult is to port the patch to 17? It's doable but a little bit tricky as the nmethod entry barriers for G1 were inteoduced with loom, which didn't exist in 17. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From coleenp at openjdk.org Mon Aug 15 21:56:35 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Aug 2022 21:56:35 GMT Subject: RFR: 8292286: Convert PlaceholderTable to ResourceHashtable [v3] In-Reply-To: References: Message-ID: On Mon, 15 Aug 2022 18:19:41 GMT, Coleen Phillimore wrote: >> This change converts the PlaceholderTable to ResourceHashtable. It's much like the ResolutionErrorTable conversion. This change has been performance tested with the previous set of testing with no regression. It's also been tested tier1-3 and 4-7 with the other tables in my patch queue. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Ioi comments. Thank you Harold and Ioi for the code reviews. I filed RFE JDK-8292383 to make the refcounting for ResourceHashtables key less error prone and this table will change for that too. ------------- PR: https://git.openjdk.org/jdk/pull/9854 From coleenp at openjdk.org Mon Aug 15 21:56:35 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Aug 2022 21:56:35 GMT Subject: Integrated: 8292286: Convert PlaceholderTable to ResourceHashtable In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 13:07:03 GMT, Coleen Phillimore wrote: > This change converts the PlaceholderTable to ResourceHashtable. It's much like the ResolutionErrorTable conversion. This change has been performance tested with the previous set of testing with no regression. It's also been tested tier1-3 and 4-7 with the other tables in my patch queue. This pull request has now been integrated. Changeset: 6e6ae596 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/6e6ae596d6bd73909b90911e01fbd0c16f6335e1 Stats: 287 lines in 6 files changed: 35 ins; 152 del; 100 mod 8292286: Convert PlaceholderTable to ResourceHashtable Reviewed-by: hseigel, iklam ------------- PR: https://git.openjdk.org/jdk/pull/9854 From dholmes at openjdk.org Mon Aug 15 22:26:20 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Aug 2022 22:26:20 GMT Subject: RFR: JDK-8292351: tty should always live In-Reply-To: References: Message-ID: On Mon, 15 Aug 2022 14:18:57 GMT, Thomas Stuefe wrote: > I don't force using stdout. I prevent the VM from crashing. Yes by forcing the use of stdout. There are users who go to great lengths to ensure nothing from the VM appears on stdout and this change would allow for such output with no way at all for the user to control it. >> Is that real concern? > Yes. My question was not directed to the PR issue but to my own comment about now forcing use of stdout when users have taken steps to prevent that, and whether this is really a concern. And I think the answer in the past has been yes - as I said there have been customers who have insisted on nothing from the VM being written to stdout. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From dholmes at openjdk.org Mon Aug 15 22:30:33 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Aug 2022 22:30:33 GMT Subject: RFR: JDK-8292351: tty should always live In-Reply-To: References: Message-ID: On Mon, 15 Aug 2022 15:11:23 GMT, Johan Sj?l?n wrote: > The goal should be to replace tty with UL UL has the same problems. UL is configured by argument parsing, so prior to that you can't log. And at some point UL is shutdown, and after that you can't log either. There is no nice solution for the initialization problem. But for termination it should be possible to defer the tty/stream cleanup to an even later point (similarly for UL). ------------- PR: https://git.openjdk.org/jdk/pull/9874 From coleenp at openjdk.org Tue Aug 16 02:22:20 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 16 Aug 2022 02:22:20 GMT Subject: RFR: 8292384: Convert AdapterHandlerTable to ResourceHashtable Message-ID: The adapter handler table was a Hashtable, and has been converted to Resourcehashtable, without any complications. Tested with tier1-3 (4-7) previously with other changes. ------------- Commit messages: - 8292384: Convert AdapterHandlerTable to ResourceHashtable Changes: https://git.openjdk.org/jdk/pull/9885/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9885&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292384 Stats: 197 lines in 2 files changed: 21 ins; 112 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/9885.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9885/head:pull/9885 PR: https://git.openjdk.org/jdk/pull/9885 From iklam at openjdk.org Tue Aug 16 04:06:10 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Aug 2022 04:06:10 GMT Subject: RFR: 8292318: Memory corruption in remove_dumptime_info Message-ID: In [JDK-8290833](https://bugs.openjdk.org/browse/JDK-8290833) (#9759), I added a table (`SystemDictionaryShared::_saved_cpcache_entries_table`) that remembers the initial state of a `ConstantPoolCache` during CDS dumping. This table is indexed with a `ConstantPoolCache*` However, `ConstantPoolCache` has a complex lifecycle, especially with class redefinition. This makes it difficult to clean up the table. The crash reported in [the current bug](https://bugs.openjdk.org/browse/JDK-8292318) happened during clean up, probably because an `InstanceKlass` was still valid but its `ConstantPool` or `ConstantPoolCache` were not. For simplification, I am now storing the information inside the `ConstantPoolCache`. To compensate for the extra space used, I moved two 32-bit integers next to each other, so the net change in size is zero. instanceKlass.cpp was reverted to the state before #9759. ------------- Commit messages: - fixed old bug in test case - 8292318: Memory corruption in remove_dumptime_info Changes: https://git.openjdk.org/jdk/pull/9887/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9887&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292318 Stats: 106 lines in 7 files changed: 20 ins; 75 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/9887.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9887/head:pull/9887 PR: https://git.openjdk.org/jdk/pull/9887 From duke at openjdk.org Tue Aug 16 04:56:34 2022 From: duke at openjdk.org (Yi-Fan Tsai) Date: Tue, 16 Aug 2022 04:56:34 GMT Subject: RFR: 8280152: AArch64: Reuse runtime call trampolines [v8] In-Reply-To: <2Rz88X0uWMdi7N4NFC36ZiMXgOhUmh0XehnaOKo6JWM=.9422ee14-4e73-47a5-a211-842fa5331391@github.com> References: <2Rz88X0uWMdi7N4NFC36ZiMXgOhUmh0XehnaOKo6JWM=.9422ee14-4e73-47a5-a211-842fa5331391@github.com> Message-ID: <6l5CGvjJBPLBQ15i4GmzNZIQHjDNW6ApSL1nVuulsqM=.9cb03a06-0ab7-4dc1-88fe-a95cac99be7c@github.com> > A trampoline stub could be generated for each runtime call. These trampolines could be duplication if the callees are the same. This change delays the stub generation and generates one stub for a distinct callee. > > Benchmark als, chi-square, dec-tree, gauss-mix, log-regression, movie-lens, naive-bayes, page-rank, fj-means, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~4.7% reduction on average. Yi-Fan Tsai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' of https://github.com/yftsai/jdk into JDK-8280152 - Grow hashtable only if a new entry is added - Merge branch 'master' of https://github.com/yftsai/jdk into JDK-8280152 - Reduce maximum hash table size and cleanup - Use ResizeableResourceHashtable - Use a hash table to deduplicate - Rename variables - Remove dead codes - Reuse runtime call trampolines ------------- Changes: https://git.openjdk.org/jdk/pull/9405/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9405&range=07 Stats: 191 lines in 5 files changed: 186 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9405.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9405/head:pull/9405 PR: https://git.openjdk.org/jdk/pull/9405 From stuefe at openjdk.org Tue Aug 16 05:29:45 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 16 Aug 2022 05:29:45 GMT Subject: RFR: JDK-8292351: tty should always live In-Reply-To: References: Message-ID: On Mon, 15 Aug 2022 22:24:02 GMT, David Holmes wrote: > > I don't force using stdout. I prevent the VM from crashing. > > Yes by forcing the use of stdout. There are users who go to great lengths to ensure nothing from the VM appears on stdout and this change would allow for such output with no way at all for the user to control it. > > > > Is that real concern? > > > Yes. > > My question was not directed to the PR issue but to my own comment about now forcing use of stdout when users have taken steps to prevent that, and whether this is really a concern. And I think the answer in the past has been yes - as I said there have been customers who have insisted on nothing from the VM being written to stdout. I'm equally fine with using stderr, which would have been my preference. I only chose stdout to keep with the standard behavior of VM output. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Tue Aug 16 05:38:14 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 16 Aug 2022 05:38:14 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> <5sG7YDdsl8g7JlNW0l40ez8OfiFudQDDSRuKZgodXhU=.cb42b06d-60a8-48c9-badd-b7d7e6a35e84@github.com> Message-ID: On Mon, 15 Aug 2022 18:38:51 GMT, Ioi Lam wrote: > Do you know how much testing is done by the community with zero? We don't test it that much in our pipeline. You could ask the Debian people (Adrian Glaubitz), IIRC they have test farms with broad platform support and use a lot of zero. ------------- PR: https://git.openjdk.org/jdk/pull/9869 From clanger at openjdk.org Tue Aug 16 05:50:38 2022 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 16 Aug 2022 05:50:38 GMT Subject: RFR: JDK-8292351: tty should always live In-Reply-To: References: Message-ID: On Mon, 15 Aug 2022 09:25:17 GMT, Thomas Stuefe wrote: > The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. > > This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. > > tty should always be safe to write to, and that is trivial to do. Would it be possible to redirect to some dummy file instead of stdout? I mean if it is just to avoid crashes and nobody cares about lost logs? ------------- PR: https://git.openjdk.org/jdk/pull/9874 From shade at openjdk.org Tue Aug 16 06:35:54 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 16 Aug 2022 06:35:54 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v4] In-Reply-To: References: Message-ID: On Mon, 15 Aug 2022 18:44:28 GMT, Ioi Lam wrote: >> Enable CDS for zero builds. `java --version` is about 2x faster now. >> >> >> $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version >> 0.034645 +- 0.000044 seconds time elapsed ( +- 0.13% ) >> $ perf stat -r 40 ./images/jdk/bin/java -version >> 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% ) >> >> I also fixed a bug in Images.gmk that always wrote the default archive to $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to have a default CDS archive. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed copyright and whitespaces Looks fine to me, with minor nits. src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 2455: > 2453: if (cache->is_vfinal()) { > 2454: callee = cache->f2_as_vfinal_method(); > 2455: if (REWRITE_BYTECODES && !UseSharedSpaces && !Arguments::is_dumping_archive()) { As we discussed with @tstuefe in another thread, the use of `UseSharedSpaces` needs the explicit `#include` of `globals.hpp`. test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestAutoCreateSharedArchiveNoDefaultArchive.java line 108: > 106: removeDefaultArchives(java_home_dst, "zero"); > 107: removeDefaultArchives(java_home_dst, "server"); > 108: removeDefaultArchives(java_home_dst, "zero"); What is the point of doing "zero" part twice? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9869 From shade at openjdk.org Tue Aug 16 06:38:32 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 16 Aug 2022 06:38:32 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> <5sG7YDdsl8g7JlNW0l40ez8OfiFudQDDSRuKZgodXhU=.cb42b06d-60a8-48c9-badd-b7d7e6a35e84@github.com> Message-ID: On Tue, 16 Aug 2022 05:36:03 GMT, Thomas Stuefe wrote: > > Do you know how much testing is done by the community with zero? We don't test it that much in our pipeline. > > You could ask the Debian people (Adrian Glaubitz), IIRC they have test farms with broad platform support and use a lot of zero. Yes, Debian seems to rely on Zero for many arches that do not have Server ports. They discover the bugs sometimes, but I think it got much better once we started doing x86_64 Zero bootcycle tests for incoming Zero patches -- it shakes out a lot of simple bugs. ------------- PR: https://git.openjdk.org/jdk/pull/9869 From stuefe at openjdk.org Tue Aug 16 07:20:20 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 16 Aug 2022 07:20:20 GMT Subject: RFR: JDK-8292351: tty should always live In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 05:46:30 GMT, Christoph Langer wrote: > Would it be possible to redirect to some dummy file instead of stdout? I mean if it is just to avoid crashes and nobody cares about lost logs? Unfortunately, that does not help. We very much want to see the output (see e.g. Discussion https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2022-August/056826.html, where NMT detected a heap corruption but was unable to print out a meaningful report since tty was NULL and it crashed). And people could object to random files popping up as well. Where would you write them? No, the more I think about this the more I am convinced that printing to stderr is the right thing to do. That is what, for instance, the C-Runtime does if it detects a stack corruption. It is the typical Unix way too, so it does not violate the principle of least surprise. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Tue Aug 16 07:25:51 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 16 Aug 2022 07:25:51 GMT Subject: RFR: JDK-8292351: tty should always live [v2] In-Reply-To: References: Message-ID: > The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. > > This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. > > tty should always be safe to write to, and that is trivial to do. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Use stderr instead of stdout ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9874/files - new: https://git.openjdk.org/jdk/pull/9874/files/1dda2102..30bf40f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9874&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9874&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9874/head:pull/9874 PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Tue Aug 16 07:38:35 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 16 Aug 2022 07:38:35 GMT Subject: RFR: JDK-8292351: tty should always live In-Reply-To: References: Message-ID: <1lejBA_cypVYPuoHiebTIXFclnzjA-FFBziRQCchB-c=.994f6119-1377-4b49-8664-077094af595c@github.com> On Mon, 15 Aug 2022 22:28:30 GMT, David Holmes wrote: > > The goal should be to replace tty with UL > > UL has the same problems. UL is configured by argument parsing, so prior to that you can't log. And at some point UL is shutdown, and after that you can't log either. UL has even more problems. You also cannot use it in signal handlers, and not in subsystems that UL itself uses unless you are really sure you know what you do. For instance, anything below os::malloc cannot use UL (including NMT). In my eyes, UL is a bit too complex and uses too much VM infrastructure for it to be a use-everywhere logging system. If you use it, you have to think if it is okay. And if people want to expand it, you have to take a lot of care in PR discussions (remember the "lets trace over network" ideas). I would love to have some sort of automatic mechanism for locally forbidding UL use. Similar to a NoHandleMark. Like a NoULMark. That way we could at least guard code sections that should not use UL, or that UL should not use. If it were only the argument parsing problem, if UL had no dependencies into the rest of the VM, we could solve that by finding an alternate way to pass logging arguments. E.g. via environment variables. But you would have to move UL initialization up the initialization order, possibly into the C++ dynamic initialization phase, and I'm sure that would not work. > > There is no nice solution for the initialization problem. But for termination it should be possible to defer the tty/stream cleanup to an even later point (similarly for UL). I agree with that. I did not pursue this for tty in this patch since I did not want to make the patch more complex than it is, and easily down-portable. One problem with UL is that it relies, I believe, on VM infrastructure. At least os::malloc and Thread::current, last time I looked. Not sure if it has more dependencies now. Prolonging UL life may therefore more difficult than just removing it from cleanup. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From chagedorn at openjdk.org Tue Aug 16 08:07:52 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 16 Aug 2022 08:07:52 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v15] In-Reply-To: References: Message-ID: > When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: > > Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 > V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec > V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 > V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df > V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 > V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d > V [libjvm.so+0x12091c9] JavaThread::run()+0x167 > V [libjvm.so+0x1206ada] Thread::call_run()+0x180 > V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f > > This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. > > This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): > > Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) > V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) > V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) > V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) > V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) > V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) > V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) > V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) > V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) > > For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. > > The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf > I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. > > The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. > > Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. > > **Testing:** > Apart from manual testing, I've added two kinds of tests: > - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. > - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. > > On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. > > To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. > > I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). > > Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! > > Thanks, > Christian Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits: - Merge branch 'master' into JDK-8242181 - Fix optimized build - Merge branch 'master' into JDK-8242181 - Merge branch 'master' into JDK-8242181 - Exclude TestDwarf.java when run with product because TraceDwarf is a develop flag - Merge branch 'master' into JDK-8242181 - Merge branch 'master' into JDK-8242181 - Fix TestDwarf for older GCC versions - Change logging from UL to tty based with new TraceDwarfLevel develop flag - Add support to parse the .debug_line section in DWARF 2 as emitted by GCC 8, add some comments - ... and 62 more: https://git.openjdk.org/jdk/compare/d1edda8f...d4a4e873 ------------- Changes: https://git.openjdk.org/jdk/pull/7126/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=7126&range=14 Stats: 2782 lines in 18 files changed: 2686 ins; 41 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/7126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/7126/head:pull/7126 PR: https://git.openjdk.org/jdk/pull/7126 From stuefe at openjdk.org Tue Aug 16 08:20:53 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 16 Aug 2022 08:20:53 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v15] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 08:07:52 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: >> >> Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> >> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. >> >> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): >> >> Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) >> >> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. >> >> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf >> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. >> >> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. >> >> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. >> >> **Testing:** >> Apart from manual testing, I've added two kinds of tests: >> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. >> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. >> >> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. >> >> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. >> >> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). >> >> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits: > > - Merge branch 'master' into JDK-8242181 > - Fix optimized build > - Merge branch 'master' into JDK-8242181 > - Merge branch 'master' into JDK-8242181 > - Exclude TestDwarf.java when run with product because TraceDwarf is a develop flag > - Merge branch 'master' into JDK-8242181 > - Merge branch 'master' into JDK-8242181 > - Fix TestDwarf for older GCC versions > - Change logging from UL to tty based with new TraceDwarfLevel develop flag > - Add support to parse the .debug_line section in DWARF 2 as emitted by GCC 8, add some comments > - ... and 62 more: https://git.openjdk.org/jdk/compare/d1edda8f...d4a4e873 Looks good to me too. We are a bit strapped for review- and test-cycles atm, therefore please go ahead and push it. This is a really useful change. If problems show up on some of our weird architectures or old Linux distros, we will deal with it then. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/7126 From chagedorn at openjdk.org Tue Aug 16 09:09:23 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 16 Aug 2022 09:09:23 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v15] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 08:07:52 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: >> >> Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> >> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. >> >> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): >> >> Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) >> >> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. >> >> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf >> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. >> >> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. >> >> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. >> >> **Testing:** >> Apart from manual testing, I've added two kinds of tests: >> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. >> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. >> >> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. >> >> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. >> >> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). >> >> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits: > > - Merge branch 'master' into JDK-8242181 > - Fix optimized build > - Merge branch 'master' into JDK-8242181 > - Merge branch 'master' into JDK-8242181 > - Exclude TestDwarf.java when run with product because TraceDwarf is a develop flag > - Merge branch 'master' into JDK-8242181 > - Merge branch 'master' into JDK-8242181 > - Fix TestDwarf for older GCC versions > - Change logging from UL to tty based with new TraceDwarfLevel develop flag > - Add support to parse the .debug_line section in DWARF 2 as emitted by GCC 8, add some comments > - ... and 62 more: https://git.openjdk.org/jdk/compare/d1edda8f...d4a4e873 Thanks Thomas for your review and assessment! That sounds good. I will give it another spin in our testing. Now that UL was replaced by `TraceDwarfLevel`, I think there are no other outstanding issues to resolve in this PR. If there are no objections, we can go ahead and integrate this - maybe at the start of next week to give some more time for feedback. Thanks, Christian ------------- PR: https://git.openjdk.org/jdk/pull/7126 From aph at openjdk.org Tue Aug 16 10:09:19 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 16 Aug 2022 10:09:19 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v6] In-Reply-To: References: Message-ID: <7-9sMaveCa-a2sxHULFPmCYf1-uudLSkm3WLzwF_UuY=.eab16718-87d4-4a2e-803a-2f60c746c0c5@github.com> On Thu, 11 Aug 2022 21:19:07 GMT, Evgeny Astigeevich wrote: >> Runtime calls are calls of non-compiled methods. Non-compiled methods stay forever in CodeCache. If they are always within the branch range, they don't need trampolines. >> >> This PR adds `is_always_within_branch_range(Address entry)`. >> >> Results from DaCapo: the total number of eliminated trampolines per a benchmark run >> >> >> +----------+--------+ >> | avrora | 15491 | >> | batik | 75837 | >> | biojava | 13927 | >> | eclipse | 414143 | >> | fop | 119267 | >> | graphchi | 7665 | >> | jme | 8279 | >> | luindex | 56061 | >> | lusearch | 50277 | >> | pmd | 132719 | >> | sunflow | 10689 | >> | tomcat | 186967 | >> | xalan | 50349 | >> | zxing | 41497 | >> +----------+--------+ >> >> >> >> Testing: >> - `tier1`...`tier2`: Passed >> - `compiler/c2/aarch64/TestTrampoline.java`: Passed >> >> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Clarify non-compiled method in comments src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 871: > 869: : CodeCache::low_bound(); > 870: return Assembler::reachable_from_branch_at(longest_branch_start, target); > 871: } When does it happen that code outside the code cache (presumably in native shared libraries) is reachable? How did you test it? ------------- PR: https://git.openjdk.org/jdk/pull/8403 From jwaters at openjdk.org Tue Aug 16 10:15:39 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 16 Aug 2022 10:15:39 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v9] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - Shift conflict check to end - Conflict check can be folded ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/a1fc9cd3..0c07454b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=07-08 Stats: 36 lines in 1 file changed: 15 ins; 13 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From aph at openjdk.org Tue Aug 16 10:19:32 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 16 Aug 2022 10:19:32 GMT Subject: RFR: 8280152: AArch64: Reuse runtime call trampolines [v8] In-Reply-To: <6l5CGvjJBPLBQ15i4GmzNZIQHjDNW6ApSL1nVuulsqM=.9cb03a06-0ab7-4dc1-88fe-a95cac99be7c@github.com> References: <2Rz88X0uWMdi7N4NFC36ZiMXgOhUmh0XehnaOKo6JWM=.9422ee14-4e73-47a5-a211-842fa5331391@github.com> <6l5CGvjJBPLBQ15i4GmzNZIQHjDNW6ApSL1nVuulsqM=.9cb03a06-0ab7-4dc1-88fe-a95cac99be7c@github.com> Message-ID: On Tue, 16 Aug 2022 04:56:34 GMT, Yi-Fan Tsai wrote: >> A trampoline stub could be generated for each runtime call. These trampolines could be duplication if the callees are the same. This change delays the stub generation and generates one stub for a distinct callee. >> >> Benchmark als, chi-square, dec-tree, gauss-mix, log-regression, movie-lens, naive-bayes, page-rank, fj-means, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~4.7% reduction on average. > > Yi-Fan Tsai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge branch 'master' of https://github.com/yftsai/jdk into JDK-8280152 > - Grow hashtable only if a new entry is added > - Merge branch 'master' of https://github.com/yftsai/jdk into JDK-8280152 > - Reduce maximum hash table size and cleanup > - Use ResizeableResourceHashtable > - Use a hash table to deduplicate > - Rename variables > - Remove dead codes > - Reuse runtime call trampolines Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9405 From jwaters at openjdk.org Tue Aug 16 10:23:31 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 16 Aug 2022 10:23:31 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/0c07454b..e271f0a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=08-09 Stats: 29 lines in 1 file changed: 4 ins; 5 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From duke at openjdk.org Tue Aug 16 10:44:23 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 16 Aug 2022 10:44:23 GMT Subject: RFR: 8290025: Remove the Sweeper [v10] In-Reply-To: <_oY0vCTPn4WV-d3qvXzoJOoUPFJBCRd_XuXdl7jKC-Q=.d5f8e298-a098-4eb7-be96-57c8f21f2cb8@github.com> References: <65HdN3ro2PsMM9ilGi5aJrxlsOUid7CbJlLF1FhJYNE=.e597499a-1a92-4721-b95d-d0268837971e@github.com> <_oY0vCTPn4WV-d3qvXzoJOoUPFJBCRd_XuXdl7jKC-Q=.d5f8e298-a098-4eb7-be96-57c8f21f2cb8@github.com> Message-ID: On Mon, 15 Aug 2022 20:42:52 GMT, Erik ?sterlund wrote: > > Hi Erik (@fisk), > > We have a real-life workload with 20k - 50k compiled methods. I'd like to test the patch with it. The workload uses jdk17. > > How difficult is to port the patch to 17? > > It's doable but a little bit tricky as the nmethod entry barriers for G1 were inteoduced with loom, which didn't exist in 17. I see. Would 18 or 19 be more suitable? ------------- PR: https://git.openjdk.org/jdk/pull/9741 From duke at openjdk.org Tue Aug 16 11:47:15 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 16 Aug 2022 11:47:15 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v6] In-Reply-To: <7-9sMaveCa-a2sxHULFPmCYf1-uudLSkm3WLzwF_UuY=.eab16718-87d4-4a2e-803a-2f60c746c0c5@github.com> References: <7-9sMaveCa-a2sxHULFPmCYf1-uudLSkm3WLzwF_UuY=.eab16718-87d4-4a2e-803a-2f60c746c0c5@github.com> Message-ID: On Tue, 16 Aug 2022 10:05:37 GMT, Andrew Haley wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Clarify non-compiled method in comments > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 871: > >> 869: : CodeCache::low_bound(); >> 870: return Assembler::reachable_from_branch_at(longest_branch_start, target); >> 871: } > > When does it happen that code outside the code cache (presumably in native shared libraries) is reachable? How did you test it? This is the fix of: [JDK-8286314](https://bugs.openjdk.org/browse/JDK-8286314): Trampoline not created for far runtime targets outside small CodeCache At the time of writing the fix I could not find how to test the fix. We don't generate such trampoline calls. I think if such calls appear, they will always be unreachable. ------------- PR: https://git.openjdk.org/jdk/pull/8403 From eosterlund at openjdk.org Tue Aug 16 11:55:24 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 16 Aug 2022 11:55:24 GMT Subject: RFR: 8290025: Remove the Sweeper [v10] In-Reply-To: <_oY0vCTPn4WV-d3qvXzoJOoUPFJBCRd_XuXdl7jKC-Q=.d5f8e298-a098-4eb7-be96-57c8f21f2cb8@github.com> References: <65HdN3ro2PsMM9ilGi5aJrxlsOUid7CbJlLF1FhJYNE=.e597499a-1a92-4721-b95d-d0268837971e@github.com> <_oY0vCTPn4WV-d3qvXzoJOoUPFJBCRd_XuXdl7jKC-Q=.d5f8e298-a098-4eb7-be96-57c8f21f2cb8@github.com> Message-ID: On Mon, 15 Aug 2022 20:42:52 GMT, Erik ?sterlund wrote: >>> Hi Erik, >>> >>> I'll take a closer look next week, and by then we will have more test runs to get a better picture. >>> >>> Meanwhile, could you please merge the change to the current head? This would help us with our ideosyncratic CI. Thank you! >>> >>> ..Thomas >> >> Thank you for having a look at this. I merged to the latest head, hope that helps! > >> Hi Erik (@fisk), >> >> We have a real-life workload with 20k - 50k compiled methods. I'd like to test the patch with it. The workload uses jdk17. >> >> How difficult is to port the patch to 17? > > It's doable but a little bit tricky as the nmethod entry barriers for G1 were inteoduced with loom, which didn't exist in 17. > > > Hi Erik (@fisk), > > > We have a real-life workload with 20k - 50k compiled methods. I'd like to test the patch with it. The workload uses jdk17. > > > How difficult is to port the patch to 17? > > > > > > It's doable but a little bit tricky as the nmethod entry barriers for G1 were inteoduced with loom, which didn't exist in 17. > > I see. Would 18 or 19 be more suitable? Yes, 19 would be more suitable. The easiest thing might be to take the current commit and build it. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From aph at openjdk.org Tue Aug 16 12:08:27 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 16 Aug 2022 12:08:27 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v6] In-Reply-To: References: <7-9sMaveCa-a2sxHULFPmCYf1-uudLSkm3WLzwF_UuY=.eab16718-87d4-4a2e-803a-2f60c746c0c5@github.com> Message-ID: On Tue, 16 Aug 2022 11:44:59 GMT, Evgeny Astigeevich wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 871: >> >>> 869: : CodeCache::low_bound(); >>> 870: return Assembler::reachable_from_branch_at(longest_branch_start, target); >>> 871: } >> >> When does it happen that code outside the code cache (presumably in native shared libraries) is reachable? How did you test it? > > This is the fix of: > [JDK-8286314](https://bugs.openjdk.org/browse/JDK-8286314): Trampoline not created for far runtime targets outside small CodeCache > > At the time of writing the fix I could not find how to test the fix. We don't generate such trampoline calls. > > I think if such calls appear, they will always be unreachable. Please take it out, then. ------------- PR: https://git.openjdk.org/jdk/pull/8403 From duke at openjdk.org Tue Aug 16 12:54:27 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 16 Aug 2022 12:54:27 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v7] In-Reply-To: References: Message-ID: > Runtime calls are calls of non-compiled methods. Non-compiled methods stay forever in CodeCache. If they are always within the branch range, they don't need trampolines. > > This PR adds `is_always_within_branch_range(Address entry)`. > > Results from DaCapo: the total number of eliminated trampolines per a benchmark run > > > +----------+--------+ > | avrora | 15491 | > | batik | 75837 | > | biojava | 13927 | > | eclipse | 414143 | > | fop | 119267 | > | graphchi | 7665 | > | jme | 8279 | > | luindex | 56061 | > | lusearch | 50277 | > | pmd | 132719 | > | sunflow | 10689 | > | tomcat | 186967 | > | xalan | 50349 | > | zxing | 41497 | > +----------+--------+ > > > > Testing: > - `tier1`...`tier2`: Passed > - `compiler/c2/aarch64/TestTrampoline.java`: Passed > > Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Always generate trampolines for calles outside CodeCache ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8403/files - new: https://git.openjdk.org/jdk/pull/8403/files/55872c47..1165b85e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8403&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8403&range=05-06 Stats: 17 lines in 1 file changed: 0 ins; 16 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/8403.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8403/head:pull/8403 PR: https://git.openjdk.org/jdk/pull/8403 From duke at openjdk.org Tue Aug 16 12:54:27 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 16 Aug 2022 12:54:27 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v6] In-Reply-To: References: <7-9sMaveCa-a2sxHULFPmCYf1-uudLSkm3WLzwF_UuY=.eab16718-87d4-4a2e-803a-2f60c746c0c5@github.com> Message-ID: <2OumSsjv72kdy4S1PRsTSj57DycPAif7FCYMW8HdaA0=.17db73f8-18fa-4836-a7d9-d5c41293885b@github.com> On Tue, 16 Aug 2022 12:04:20 GMT, Andrew Haley wrote: >> This is the fix of: >> [JDK-8286314](https://bugs.openjdk.org/browse/JDK-8286314): Trampoline not created for far runtime targets outside small CodeCache >> >> At the time of writing the fix I could not find how to test the fix. We don't generate such trampoline calls. >> >> I think if such calls appear, they will always be unreachable. > > Please take it out, then. Done ------------- PR: https://git.openjdk.org/jdk/pull/8403 From duke at openjdk.org Tue Aug 16 13:09:26 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 16 Aug 2022 13:09:26 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v8] In-Reply-To: References: Message-ID: > Runtime calls are calls of non-compiled methods. Non-compiled methods stay forever in CodeCache. If they are always within the branch range, they don't need trampolines. > > This PR adds `is_always_within_branch_range(Address entry)`. > > Results from DaCapo: the total number of eliminated trampolines per a benchmark run > > > +----------+--------+ > | avrora | 15491 | > | batik | 75837 | > | biojava | 13927 | > | eclipse | 414143 | > | fop | 119267 | > | graphchi | 7665 | > | jme | 8279 | > | luindex | 56061 | > | lusearch | 50277 | > | pmd | 132719 | > | sunflow | 10689 | > | tomcat | 186967 | > | xalan | 50349 | > | zxing | 41497 | > +----------+--------+ > > > > Testing: > - `tier1`...`tier2`: Passed > - `compiler/c2/aarch64/TestTrampoline.java`: Passed > > Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Simplify checks in is_always_within_branch_range ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8403/files - new: https://git.openjdk.org/jdk/pull/8403/files/1165b85e..7c475a9e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8403&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8403&range=06-07 Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/8403.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8403/head:pull/8403 PR: https://git.openjdk.org/jdk/pull/8403 From duke at openjdk.org Tue Aug 16 13:09:28 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 16 Aug 2022 13:09:28 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v6] In-Reply-To: <2OumSsjv72kdy4S1PRsTSj57DycPAif7FCYMW8HdaA0=.17db73f8-18fa-4836-a7d9-d5c41293885b@github.com> References: <7-9sMaveCa-a2sxHULFPmCYf1-uudLSkm3WLzwF_UuY=.eab16718-87d4-4a2e-803a-2f60c746c0c5@github.com> <2OumSsjv72kdy4S1PRsTSj57DycPAif7FCYMW8HdaA0=.17db73f8-18fa-4836-a7d9-d5c41293885b@github.com> Message-ID: On Tue, 16 Aug 2022 12:49:40 GMT, Evgeny Astigeevich wrote: >> Please take it out, then. > > Done Now everything outside CodeCache is always unreachable. ------------- PR: https://git.openjdk.org/jdk/pull/8403 From duke at openjdk.org Tue Aug 16 13:36:18 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Tue, 16 Aug 2022 13:36:18 GMT Subject: RFR: JDK-8292351: tty should always live In-Reply-To: <1lejBA_cypVYPuoHiebTIXFclnzjA-FFBziRQCchB-c=.994f6119-1377-4b49-8664-077094af595c@github.com> References: <1lejBA_cypVYPuoHiebTIXFclnzjA-FFBziRQCchB-c=.994f6119-1377-4b49-8664-077094af595c@github.com> Message-ID: On Tue, 16 Aug 2022 07:34:41 GMT, Thomas Stuefe wrote: > > > The goal should be to replace tty with UL > > > > > > UL has the same problems. UL is configured by argument parsing, so prior to that you can't log. And at some point UL is shutdown, and after that you can't log either. > > UL has even more problems. You also cannot use it in signal handlers, and not in subsystems that UL itself uses unless you are really sure you know what you do. For instance, anything below os::malloc cannot use UL (including NMT). To be clear, I said: >The goal should be to replace tty with UL *in as many cases as possible*. In other words, tty should be used when UL cannot be used. Therefore this change is good, because it makes tty viable in more places where UL is not viable. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From clanger at openjdk.org Tue Aug 16 13:59:35 2022 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 16 Aug 2022 13:59:35 GMT Subject: RFR: JDK-8292351: tty should always live [v2] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 07:25:51 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Use stderr instead of stdout OK, I think using stderr is a good vote then. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Tue Aug 16 14:02:47 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 16 Aug 2022 14:02:47 GMT Subject: RFR: JDK-8292351: tty should always live [v2] In-Reply-To: References: Message-ID: <54Hdk6qhlJGa8vM3VXao0cwVm7S7HFcP2MopE87gpCc=.6f19cfa5-4ecb-4bba-8e53-7a12709fa3e6@github.com> On Tue, 16 Aug 2022 13:57:10 GMT, Christoph Langer wrote: > OK, I think using stderr is a good vote then. Thank you @RealCLanger ! ------------- PR: https://git.openjdk.org/jdk/pull/9874 From hseigel at openjdk.org Tue Aug 16 14:09:13 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 16 Aug 2022 14:09:13 GMT Subject: RFR: 8292384: Convert AdapterHandlerTable to ResourceHashtable In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 02:14:41 GMT, Coleen Phillimore wrote: > The adapter handler table was a Hashtable, and has been converted to Resourcehashtable, without any complications. > Tested with tier1-3 (4-7) previously with other changes. The changes look good. Thanks for doing this. Perhaps you should remove its instantiation (template class BasicHashtableEntry;) from hashtable.cpp. ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.org/jdk/pull/9885 From stuefe at openjdk.org Tue Aug 16 14:11:53 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 16 Aug 2022 14:11:53 GMT Subject: RFR: JDK-8292351: tty should always live [v3] In-Reply-To: References: Message-ID: > The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. > > This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. > > tty should always be safe to write to, and that is trivial to do. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Rename the stream object ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9874/files - new: https://git.openjdk.org/jdk/pull/9874/files/30bf40f8..83359b4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9874&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9874&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9874/head:pull/9874 PR: https://git.openjdk.org/jdk/pull/9874 From coleenp at openjdk.org Tue Aug 16 15:51:12 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 16 Aug 2022 15:51:12 GMT Subject: RFR: 8292448: Convert BitMapFragmentTable to ResourceHashtable Message-ID: This is an uncomplicated conversion of the bitmap fragment table into a ResizeableResourceHashtable. Ran tiers 1-3 and 4-7 with other changes, and verified that the memory for ResourceHashtableStorage is freed. ------------- Commit messages: - 8292448: Convert BitMapFragmentTable to ResourceHashtable Changes: https://git.openjdk.org/jdk/pull/9893/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9893&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292448 Stats: 85 lines in 2 files changed: 1 ins; 65 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/9893.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9893/head:pull/9893 PR: https://git.openjdk.org/jdk/pull/9893 From coleenp at openjdk.org Tue Aug 16 16:04:12 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 16 Aug 2022 16:04:12 GMT Subject: RFR: 8292384: Convert AdapterHandlerTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: > The adapter handler table was a Hashtable, and has been converted to Resourcehashtable, without any complications. > Tested with tier1-3 (4-7) previously with other changes. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove the mtCode Hashtable instantiations. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9885/files - new: https://git.openjdk.org/jdk/pull/9885/files/6f4cd93d..bee86454 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9885&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9885&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9885.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9885/head:pull/9885 PR: https://git.openjdk.org/jdk/pull/9885 From coleenp at openjdk.org Tue Aug 16 16:04:14 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 16 Aug 2022 16:04:14 GMT Subject: RFR: 8292384: Convert AdapterHandlerTable to ResourceHashtable In-Reply-To: References: Message-ID: <_z2l4LZM-PeLY21WT6R4clSfKv9p-gLApq-mkYU0sYE=.3db9eb6f-782f-4911-a557-34364b31c05e@github.com> On Tue, 16 Aug 2022 02:14:41 GMT, Coleen Phillimore wrote: > The adapter handler table was a Hashtable, and has been converted to Resourcehashtable, without any complications. > Tested with tier1-3 (4-7) previously with other changes. Thank you for reviewing this, Harold. I removed the mtCode instantiation in hashtable.cpp. There are a few leftovers from other things that have been removed, that I'll delete in a separate change. ------------- PR: https://git.openjdk.org/jdk/pull/9885 From coleenp at openjdk.org Tue Aug 16 16:10:15 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 16 Aug 2022 16:10:15 GMT Subject: RFR: 8292448: Convert BitMapFragmentTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: > This is an uncomplicated conversion of the bitmap fragment table into a ResizeableResourceHashtable. Ran tiers 1-3 and 4-7 with other changes, and verified that the memory for ResourceHashtableStorage is freed. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove mtTracing old Hashtable instantiation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9893/files - new: https://git.openjdk.org/jdk/pull/9893/files/6b2b8b4d..74c15051 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9893&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9893&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9893.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9893/head:pull/9893 PR: https://git.openjdk.org/jdk/pull/9893 From iklam at openjdk.org Tue Aug 16 16:14:21 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Aug 2022 16:14:21 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> <5sG7YDdsl8g7JlNW0l40ez8OfiFudQDDSRuKZgodXhU=.cb42b06d-60a8-48c9-badd-b7d7e6a35e84@github.com> Message-ID: On Tue, 16 Aug 2022 06:36:26 GMT, Aleksey Shipilev wrote: > > Do you know how much testing is done by the community with zero? We don't test it that much in our pipeline. > > You could ask the Debian people (Adrian Glaubitz), IIRC they have test farms with broad platform support and use a lot of zero. @glaubitz, could you try out this PR and see if it might introduce any regressions? I'd really appreciate your help. ------------- PR: https://git.openjdk.org/jdk/pull/9869 From iklam at openjdk.org Tue Aug 16 16:36:59 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Aug 2022 16:36:59 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v5] In-Reply-To: References: Message-ID: > Enable CDS for zero builds. `java --version` is about 2x faster now. > > > $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version > 0.034645 +- 0.000044 seconds time elapsed ( +- 0.13% ) > $ perf stat -r 40 ./images/jdk/bin/java -version > 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% ) > > I also fixed a bug in Images.gmk that always wrote the default archive to $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to have a default CDS archive. Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - fixed typo in test - also disable _fast_invokevfinal for dynamic dump ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9869/files - new: https://git.openjdk.org/jdk/pull/9869/files/94fd577e..eb0e295d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9869&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9869&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9869/head:pull/9869 PR: https://git.openjdk.org/jdk/pull/9869 From iklam at openjdk.org Tue Aug 16 16:37:05 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Aug 2022 16:37:05 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v4] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 06:31:41 GMT, Aleksey Shipilev wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed copyright and whitespaces > > src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 2455: > >> 2453: if (cache->is_vfinal()) { >> 2454: callee = cache->f2_as_vfinal_method(); >> 2455: if (REWRITE_BYTECODES && !UseSharedSpaces && !Arguments::is_dumping_archive()) { > > As we discussed with @tstuefe in another thread, the use of `UseSharedSpaces` needs the explicit `#include` of `globals.hpp`. When running with dynamic dump (`-XX:ArchiveClassesAtExit=foo.jsa`), `UseSharedSpaces` is true, so it's possible for a method to be rewritten here, and later dumped into the CDS archive). I think we should remove `!UseSharedSpaces`. I'll try to write a test case for it. If I understand correctly, even if `cache->is_vfinal()` is true at dump time, it's not guarantee to be true at run time (we might load a different version of the class that contains the target method). > test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestAutoCreateSharedArchiveNoDefaultArchive.java line 108: > >> 106: removeDefaultArchives(java_home_dst, "zero"); >> 107: removeDefaultArchives(java_home_dst, "server"); >> 108: removeDefaultArchives(java_home_dst, "zero"); > > What is the point of doing "zero" part twice? Fixed. It should be "client". ------------- PR: https://git.openjdk.org/jdk/pull/9869 From psandoz at openjdk.org Tue Aug 16 16:39:18 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 16 Aug 2022 16:39:18 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 21:58:40 GMT, Vladimir Kozlov wrote: > Please add JMH microbenchmark and show results. Also please update the unit tests to run with and without the intrinsics enabled. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From shade at openjdk.org Tue Aug 16 16:52:18 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 16 Aug 2022 16:52:18 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v4] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 16:30:40 GMT, Ioi Lam wrote: >> src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 2455: >> >>> 2453: if (cache->is_vfinal()) { >>> 2454: callee = cache->f2_as_vfinal_method(); >>> 2455: if (REWRITE_BYTECODES && !UseSharedSpaces && !Arguments::is_dumping_archive()) { >> >> As we discussed with @tstuefe in another thread, the use of `UseSharedSpaces` needs the explicit `#include` of `globals.hpp`. > > When running with dynamic dump (`-XX:ArchiveClassesAtExit=foo.jsa`), `UseSharedSpaces` is true, so it's possible for a method to be rewritten here, and later dumped into the CDS archive). > > I think we should remove `!UseSharedSpaces`. I'll try to write a test case for it. If I understand correctly, even if `cache->is_vfinal()` is true at dump time, it's not guarantee to be true at run time (we might load a different version of the class that contains the target method). I thought if we run with dynamic dump, then `Arguments::is_dumping_archive()` is `false`, and we don't rewrite. Anyway, if you remove `!UseSharedSpaces` here, like you did in PR update, then this happens during Linux x86_64 Zero build: $ CONF=linux-x86_64-zero-fastdebug make images ... Creating support/classlist.jar ------------- PR: https://git.openjdk.org/jdk/pull/9869 From iklam at openjdk.org Tue Aug 16 18:23:15 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Aug 2022 18:23:15 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v6] In-Reply-To: References: Message-ID: > Enable CDS for zero builds. `java --version` is about 2x faster now. > > > $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version > 0.034645 +- 0.000044 seconds time elapsed ( +- 0.13% ) > $ perf stat -r 40 ./images/jdk/bin/java -version > 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% ) > > I also fixed a bug in Images.gmk that always wrote the default archive to $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to have a default CDS archive. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: added !UseSharedSpaces back to _fast_invokevfinal check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9869/files - new: https://git.openjdk.org/jdk/pull/9869/files/eb0e295d..8e4bef9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9869&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9869&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9869/head:pull/9869 PR: https://git.openjdk.org/jdk/pull/9869 From iklam at openjdk.org Tue Aug 16 18:23:17 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Aug 2022 18:23:17 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v4] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 16:50:09 GMT, Aleksey Shipilev wrote: >> When running with dynamic dump (`-XX:ArchiveClassesAtExit=foo.jsa`), `UseSharedSpaces` is true, so it's possible for a method to be rewritten here, and later dumped into the CDS archive). >> >> I think we should remove `!UseSharedSpaces`. I'll try to write a test case for it. If I understand correctly, even if `cache->is_vfinal()` is true at dump time, it's not guarantee to be true at run time (we might load a different version of the class that contains the target method). > > I thought if we run with dynamic dump, then `Arguments::is_dumping_archive()` is `false`, and we don't rewrite. > > Anyway, if you remove `!UseSharedSpaces` here, like you did in PR update, then this happens during Linux x86_64 Zero build: > > > $ CONF=linux-x86_64-zero-fastdebug make images > ... > Creating support/classlist.jar You're right. I added the `!UseSharedSpaces` back. I misread the code :-( ------------- PR: https://git.openjdk.org/jdk/pull/9869 From kbarrett at openjdk.org Tue Aug 16 18:55:12 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 16 Aug 2022 18:55:12 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 04:44:51 GMT, David Holmes wrote: > > Multi-Reader Single-Writer mutex > > Sorry to bikeshed but such a thing is called a ReadWriteLock or a ReadersWriterLock or something similar - can we please use familiar nomenclature here (even rwlock as per POSIX). "mutex" is a contraction of mutual-exclusion and as readers are not mutually exclusive it is an oxymoron to talk about a "multi-reader mutex". Thanks. For what it's worth, C++ Standard Library uses "mutex" to refer to an object that gets locked, and uses "lock" to refer to an RAII object that locks a "mutex". So it has, for example, `std::shared_mutex`, which is multi-reader/single-writer. The idea being that a "mutex" provides some kind of mutual exclusion - in the case of shared_mutex readers (multiple) are excluded from any writer, and writers are exclusive from each other. I'd prefer that to calling these new things "locks". ------------- PR: https://git.openjdk.org/jdk/pull/9838 From kbarrett at openjdk.org Tue Aug 16 19:53:12 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 16 Aug 2022 19:53:12 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 15:18:10 GMT, Johan Sj?l?n wrote: > May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? > > This PR does 3 things: > > * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot > * Adds some new utilities for writing multi-threaded tests. > * Adds some tests for MRSW Mutex using these new utilities > > The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 > > [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp HotSpot Mutex has a rank, used (in debug builds) to detect potential deadlock situations. These new mutexes don't have that feature, and don't interact with Mutex in that way. The rank system has pros and cons, but I'm not sure just ignoring here is a good thing. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From kbarrett at openjdk.org Tue Aug 16 20:22:17 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 16 Aug 2022 20:22:17 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 15:18:10 GMT, Johan Sj?l?n wrote: > May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? > > This PR does 3 things: > > * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot > * Adds some new utilities for writing multi-threaded tests. > * Adds some tests for MRSW Mutex using these new utilities > > The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 > > [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp What is the source of the algorithm being used here? Is there a correctness proof? How does it compare with, for example, Terekhov's algorithm? ------------- PR: https://git.openjdk.org/jdk/pull/9838 From kbarrett at openjdk.org Tue Aug 16 20:38:11 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 16 Aug 2022 20:38:11 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 15:18:10 GMT, Johan Sj?l?n wrote: > May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? > > This PR does 3 things: > > * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot > * Adds some new utilities for writing multi-threaded tests. > * Adds some tests for MRSW Mutex using these new utilities > > The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 > > [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp src/hotspot/share/runtime/mrswMutex.hpp line 63: > 61: Locker(T* lock) > 62: : _lock(lock) { > 63: if (_lock != nullptr) { When would it ever make sense for the `lock` argument to be nullptr? Instead assert in the constructor that it is not? src/hotspot/share/runtime/mrswMutex.hpp line 126: > 124: if (count != 0) { > 125: // Do requested transition before blocking > 126: WriterTransition tbivm(JavaThread::current()); These are only usable from JavaThreads. One of the intended use-cases involves UL. UL is used from non-JavaThreads. That seems like a problem for the intended use-case, and possibly for others. At the very least it should be documented as being limited to JavaThread. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From iklam at openjdk.org Tue Aug 16 20:48:05 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Aug 2022 20:48:05 GMT Subject: RFR: 8292318: Memory corruption in remove_dumptime_info [v2] In-Reply-To: References: Message-ID: > In [JDK-8290833](https://bugs.openjdk.org/browse/JDK-8290833) (#9759), I added a table (`SystemDictionaryShared::_saved_cpcache_entries_table`) that remembers the initial state of a `ConstantPoolCache` during CDS dumping. This table is indexed with a `ConstantPoolCache*` > > However, `ConstantPoolCache` has a complex lifecycle, especially with class redefinition. This makes it difficult to clean up the table. The crash reported in [the current bug](https://bugs.openjdk.org/browse/JDK-8292318) happened during clean up, probably because an `InstanceKlass` was still valid but its `ConstantPool` or `ConstantPoolCache` were not. > > For simplification, I am now storing the information inside the `ConstantPoolCache`. To compensate for the extra space used, I moved two 32-bit integers next to each other, so the net change in size is zero. > > instanceKlass.cpp was reverted to the state before #9759. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: added comments about what _initial_entries points to ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9887/files - new: https://git.openjdk.org/jdk/pull/9887/files/7d38f55f..a2872fae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9887&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9887&range=00-01 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9887.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9887/head:pull/9887 PR: https://git.openjdk.org/jdk/pull/9887 From coleenp at openjdk.org Tue Aug 16 20:54:17 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 16 Aug 2022 20:54:17 GMT Subject: RFR: 8292318: Memory corruption in remove_dumptime_info [v2] In-Reply-To: References: Message-ID: <1qMA2X25OmyXDV_YN0I_ZKIHJmm9JnIgVCcdaMyAGWU=.5dc1f065-fecb-4fd1-9c60-116de6656c3f@github.com> On Tue, 16 Aug 2022 20:48:05 GMT, Ioi Lam wrote: >> In [JDK-8290833](https://bugs.openjdk.org/browse/JDK-8290833) (#9759), I added a table (`SystemDictionaryShared::_saved_cpcache_entries_table`) that remembers the initial state of a `ConstantPoolCache` during CDS dumping. This table is indexed with a `ConstantPoolCache*` >> >> However, `ConstantPoolCache` has a complex lifecycle, especially with class redefinition. This makes it difficult to clean up the table. The crash reported in [the current bug](https://bugs.openjdk.org/browse/JDK-8292318) happened during clean up, probably because an `InstanceKlass` was still valid but its `ConstantPool` or `ConstantPoolCache` were not. >> >> For simplification, I am now storing the information inside the `ConstantPoolCache`. To compensate for the extra space used, I moved two 32-bit integers next to each other, so the net change in size is zero. >> >> instanceKlass.cpp was reverted to the state before #9759. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > added comments about what _initial_entries points to This looks good. This makes sense to me with the comments. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/9887 From coleenp at openjdk.org Tue Aug 16 20:55:20 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 16 Aug 2022 20:55:20 GMT Subject: RFR: 8292448: Convert BitMapFragmentTable to ResourceHashtable [v3] In-Reply-To: References: Message-ID: <3RjMB_nHPVj5hYmwsBzo8d3teAACs8o3fZSKJ9ccfPw=.a7bce305-4e78-41f4-a168-f21a30df9541@github.com> > This is an uncomplicated conversion of the bitmap fragment table into a ResizeableResourceHashtable. Ran tiers 1-3 and 4-7 with other changes, and verified that the memory for ResourceHashtableStorage is freed. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove explicit deleter. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9893/files - new: https://git.openjdk.org/jdk/pull/9893/files/74c15051..e17fd218 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9893&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9893&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9893.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9893/head:pull/9893 PR: https://git.openjdk.org/jdk/pull/9893 From iklam at openjdk.org Tue Aug 16 20:55:22 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Aug 2022 20:55:22 GMT Subject: RFR: 8292448: Convert BitMapFragmentTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 16:10:15 GMT, Coleen Phillimore wrote: >> This is an uncomplicated conversion of the bitmap fragment table into a ResizeableResourceHashtable. Ran tiers 1-3 and 4-7 with other changes, and verified that the memory for ResourceHashtableStorage is freed. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove mtTracing old Hashtable instantiation. Looks good, but I think the explicit delete is not necessary. src/hotspot/share/utilities/objectBitSet.inline.hpp line 63: > 61: }; > 62: Deleter deleter; > 63: _bitmap_fragments.unlink(&deleter); This shouldn't be necessary. The destructor of _bitmap_fragments will be implicitly called and will free all of its entries. ------------- PR: https://git.openjdk.org/jdk/pull/9893 From coleenp at openjdk.org Tue Aug 16 20:55:24 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 16 Aug 2022 20:55:24 GMT Subject: RFR: 8292448: Convert BitMapFragmentTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 20:07:02 GMT, Ioi Lam wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove mtTracing old Hashtable instantiation. > > src/hotspot/share/utilities/objectBitSet.inline.hpp line 63: > >> 61: }; >> 62: Deleter deleter; >> 63: _bitmap_fragments.unlink(&deleter); > > This shouldn't be necessary. The destructor of _bitmap_fragments will be implicitly called and will free all of its entries. Yes, I added a temporary assert and indeed it is. Thanks for pointing this out. ------------- PR: https://git.openjdk.org/jdk/pull/9893 From coleenp at openjdk.org Tue Aug 16 20:55:25 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 16 Aug 2022 20:55:25 GMT Subject: RFR: 8292448: Convert BitMapFragmentTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 20:51:00 GMT, Coleen Phillimore wrote: >> src/hotspot/share/utilities/objectBitSet.inline.hpp line 63: >> >>> 61: }; >>> 62: Deleter deleter; >>> 63: _bitmap_fragments.unlink(&deleter); >> >> This shouldn't be necessary. The destructor of _bitmap_fragments will be implicitly called and will free all of its entries. > > Yes, I added a temporary assert and indeed it is. Thanks for pointing this out. I'd actually tested with the version without it and then thought I needed it this morning, so I'm glad I don't need it. ------------- PR: https://git.openjdk.org/jdk/pull/9893 From iklam at openjdk.org Tue Aug 16 23:05:29 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Aug 2022 23:05:29 GMT Subject: RFR: 8292448: Convert BitMapFragmentTable to ResourceHashtable [v3] In-Reply-To: <3RjMB_nHPVj5hYmwsBzo8d3teAACs8o3fZSKJ9ccfPw=.a7bce305-4e78-41f4-a168-f21a30df9541@github.com> References: <3RjMB_nHPVj5hYmwsBzo8d3teAACs8o3fZSKJ9ccfPw=.a7bce305-4e78-41f4-a168-f21a30df9541@github.com> Message-ID: On Tue, 16 Aug 2022 20:55:20 GMT, Coleen Phillimore wrote: >> This is an uncomplicated conversion of the bitmap fragment table into a ResizeableResourceHashtable. Ran tiers 1-3 and 4-7 with other changes, and verified that the memory for ResourceHashtableStorage is freed. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove explicit deleter. Looks good. A lot of lines removed! ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/9893 From ccheung at openjdk.org Wed Aug 17 05:00:20 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 17 Aug 2022 05:00:20 GMT Subject: RFR: 8292318: Memory corruption in remove_dumptime_info [v2] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 20:48:05 GMT, Ioi Lam wrote: >> In [JDK-8290833](https://bugs.openjdk.org/browse/JDK-8290833) (#9759), I added a table (`SystemDictionaryShared::_saved_cpcache_entries_table`) that remembers the initial state of a `ConstantPoolCache` during CDS dumping. This table is indexed with a `ConstantPoolCache*` >> >> However, `ConstantPoolCache` has a complex lifecycle, especially with class redefinition. This makes it difficult to clean up the table. The crash reported in [the current bug](https://bugs.openjdk.org/browse/JDK-8292318) happened during clean up, probably because an `InstanceKlass` was still valid but its `ConstantPool` or `ConstantPoolCache` were not. >> >> For simplification, I am now storing the information inside the `ConstantPoolCache`. To compensate for the extra space used, I moved two 32-bit integers next to each other, so the net change in size is zero. >> >> instanceKlass.cpp was reverted to the state before #9759. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > added comments about what _initial_entries points to I've one question. Looks good otherwise. src/hotspot/share/oops/cpCache.cpp line 722: > 720: #if INCLUDE_CDS > 721: MetadataFactory::free_array(data, _initial_entries); > 722: _initial_entries = NULL; Should the above be inside the following condition like before? `if (Arguments::is_dumping_archive()) {` ------------- PR: https://git.openjdk.org/jdk/pull/9887 From duke at openjdk.org Wed Aug 17 07:17:41 2022 From: duke at openjdk.org (Remilia Scarlet) Date: Wed, 17 Aug 2022 07:17:41 GMT Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls In-Reply-To: References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com> Message-ID: On Tue, 5 Jul 2022 17:51:05 GMT, Evgeny Astigeevich wrote: >>> If we never patch the branch to the interpreter, we can optimize it at link time either to a direct branch or an adrp based far jump. I also created https://bugs.openjdk.org/browse/JDK-8286142 to reduce metadata mov instructions. >> >> If we emit the address of the interpreter once, at the start of the stub section, we can replace the branch to the interpreter with >> `ldr rscratch1, adr; br rscratch1`. > > Hi Andrew(@theRealAph), > Your comments are usually highly useful and help to identify missed issues. > Do you have any of them? > Thanks, > Evgeny Hi @eastig , I'd like to ask you how to get the experiment results, aka. `Saved bytes`, `Nmethods with shared stubs`,`Final # of nmethods`. Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/8816 From sgehwolf at openjdk.org Wed Aug 17 09:09:12 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 17 Aug 2022 09:09:12 GMT Subject: RFR: JDK-8292351: tty should always live [v3] In-Reply-To: References: Message-ID: <8oK02fWuzGUVLjCgCTGuDiqFohK4Fye9Q2D6wClpAzo=.e8fe9a6f-986e-4ef4-8913-21985f9d828d@github.com> On Tue, 16 Aug 2022 14:11:53 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Rename the stream object src/hotspot/share/utilities/ostream.cpp line 427: > 425: // The "real" tty is implemented by class defaultStream. But that cannot be used pre-VM-init > 426: // since its behavior depends on VM arguments that are not parsed yet. Therefore we point tty > 427: // to a simple always functioning stdout fdstream. Nit: `s/stdout/stderr/` in the comment above. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Wed Aug 17 09:30:48 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 17 Aug 2022 09:30:48 GMT Subject: RFR: JDK-8292351: tty should always live [v4] In-Reply-To: References: Message-ID: > The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. > > This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. > > tty should always be safe to write to, and that is trivial to do. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Change comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9874/files - new: https://git.openjdk.org/jdk/pull/9874/files/83359b4e..f119efc6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9874&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9874&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9874/head:pull/9874 PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Wed Aug 17 09:30:48 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 17 Aug 2022 09:30:48 GMT Subject: RFR: JDK-8292351: tty should always live [v3] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 14:11:53 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Rename the stream object Thanks @jerboaa. Comment changed as requested. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From sgehwolf at openjdk.org Wed Aug 17 09:30:48 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 17 Aug 2022 09:30:48 GMT Subject: RFR: JDK-8292351: tty should always live [v3] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 14:11:53 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Rename the stream object Thanks. Looks fine. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From duke at openjdk.org Wed Aug 17 09:52:17 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 17 Aug 2022 09:52:17 GMT Subject: RFR: 8292446: Make TableRateStatistics optional in CHT Message-ID: Right now the footprint of disabling statistics for tables where they're not used is minimal as they're single instance and static. We're working on using CHT in more contexts, where it will be dynamically allocated, and then these changes will add up to something more substantial. ------------- Commit messages: - Disable statistics where they are not used - Optional stats Changes: https://git.openjdk.org/jdk/pull/9899/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9899&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292446 Stats: 54 lines in 7 files changed: 27 ins; 11 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/9899.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9899/head:pull/9899 PR: https://git.openjdk.org/jdk/pull/9899 From stuefe at openjdk.org Wed Aug 17 10:36:21 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 17 Aug 2022 10:36:21 GMT Subject: RFR: JDK-8292351: tty should always live [v3] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 09:26:55 GMT, Severin Gehwolf wrote: > Thanks. Looks fine. Thank you! Mind approving then :-) ? ------------- PR: https://git.openjdk.org/jdk/pull/9874 From rehn at openjdk.org Wed Aug 17 12:05:21 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 17 Aug 2022 12:05:21 GMT Subject: RFR: 8292384: Convert AdapterHandlerTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 16:04:12 GMT, Coleen Phillimore wrote: >> The adapter handler table was a Hashtable, and has been converted to Resourcehashtable, without any complications. >> Tested with tier1-3 (4-7) previously with other changes. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove the mtCode Hashtable instantiations. Thank! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9885 From rehn at openjdk.org Wed Aug 17 12:07:52 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 17 Aug 2022 12:07:52 GMT Subject: RFR: 8292448: Convert BitMapFragmentTable to ResourceHashtable [v3] In-Reply-To: <3RjMB_nHPVj5hYmwsBzo8d3teAACs8o3fZSKJ9ccfPw=.a7bce305-4e78-41f4-a168-f21a30df9541@github.com> References: <3RjMB_nHPVj5hYmwsBzo8d3teAACs8o3fZSKJ9ccfPw=.a7bce305-4e78-41f4-a168-f21a30df9541@github.com> Message-ID: On Tue, 16 Aug 2022 20:55:20 GMT, Coleen Phillimore wrote: >> This is an uncomplicated conversion of the bitmap fragment table into a ResizeableResourceHashtable. Ran tiers 1-3 and 4-7 with other changes, and verified that the memory for ResourceHashtableStorage is freed. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove explicit deleter. Thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9893 From duke at openjdk.org Wed Aug 17 12:11:23 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Wed, 17 Aug 2022 12:11:23 GMT Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls In-Reply-To: References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com> Message-ID: On Tue, 5 Jul 2022 17:51:05 GMT, Evgeny Astigeevich wrote: >>> If we never patch the branch to the interpreter, we can optimize it at link time either to a direct branch or an adrp based far jump. I also created https://bugs.openjdk.org/browse/JDK-8286142 to reduce metadata mov instructions. >> >> If we emit the address of the interpreter once, at the start of the stub section, we can replace the branch to the interpreter with >> `ldr rscratch1, adr; br rscratch1`. > > Hi Andrew(@theRealAph), > Your comments are usually highly useful and help to identify missed issues. > Do you have any of them? > Thanks, > Evgeny > Hi @eastig , I'd like to ask you how to get the experiment results, aka. `Saved bytes`, `Nmethods with shared stubs`,`Final # of nmethods`. Thank you! You can get `Final # of nmethods` with `-XX:+PrintCodeCache`. To get `Saved bytes`, `Nmethods with shared stubs` you need to instrument `emit_shared_stubs_to_interp` to count shared stubs and nmethods sharing them. ------------- PR: https://git.openjdk.org/jdk/pull/8816 From duke at openjdk.org Wed Aug 17 12:12:24 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Wed, 17 Aug 2022 12:12:24 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v6] In-Reply-To: References: <7-9sMaveCa-a2sxHULFPmCYf1-uudLSkm3WLzwF_UuY=.eab16718-87d4-4a2e-803a-2f60c746c0c5@github.com> Message-ID: On Tue, 16 Aug 2022 12:04:20 GMT, Andrew Haley wrote: >> This is the fix of: >> [JDK-8286314](https://bugs.openjdk.org/browse/JDK-8286314): Trampoline not created for far runtime targets outside small CodeCache >> >> At the time of writing the fix I could not find how to test the fix. We don't generate such trampoline calls. >> >> I think if such calls appear, they will always be unreachable. > > Please take it out, then. Hi @theRealAph, Do you have any other comments? Thanks, Evgeny ------------- PR: https://git.openjdk.org/jdk/pull/8403 From coleenp at openjdk.org Wed Aug 17 12:20:42 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 17 Aug 2022 12:20:42 GMT Subject: RFR: 8292448: Convert BitMapFragmentTable to ResourceHashtable [v3] In-Reply-To: <3RjMB_nHPVj5hYmwsBzo8d3teAACs8o3fZSKJ9ccfPw=.a7bce305-4e78-41f4-a168-f21a30df9541@github.com> References: <3RjMB_nHPVj5hYmwsBzo8d3teAACs8o3fZSKJ9ccfPw=.a7bce305-4e78-41f4-a168-f21a30df9541@github.com> Message-ID: On Tue, 16 Aug 2022 20:55:20 GMT, Coleen Phillimore wrote: >> This is an uncomplicated conversion of the bitmap fragment table into a ResizeableResourceHashtable. Ran tiers 1-3 and 4-7 with other changes, and verified that the memory for ResourceHashtableStorage is freed. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove explicit deleter. Thanks for the reviews, Ioi and Robbin! ------------- PR: https://git.openjdk.org/jdk/pull/9893 From coleenp at openjdk.org Wed Aug 17 12:20:43 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 17 Aug 2022 12:20:43 GMT Subject: Integrated: 8292448: Convert BitMapFragmentTable to ResourceHashtable In-Reply-To: References: Message-ID: <9j1rcCZGvOQQghVkYnhD9Zw6qQofY07UYJUEhCF9rUI=.966ac8d8-7b67-4a09-ba36-77aae67cf36a@github.com> On Tue, 16 Aug 2022 15:41:14 GMT, Coleen Phillimore wrote: > This is an uncomplicated conversion of the bitmap fragment table into a ResizeableResourceHashtable. Ran tiers 1-3 and 4-7 with other changes, and verified that the memory for ResourceHashtableStorage is freed. This pull request has now been integrated. Changeset: e230719a Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/e230719ad3cc9e70511d7baa6338bb77cd038139 Stats: 86 lines in 3 files changed: 0 ins; 72 del; 14 mod 8292448: Convert BitMapFragmentTable to ResourceHashtable Reviewed-by: iklam, rehn ------------- PR: https://git.openjdk.org/jdk/pull/9893 From dholmes at openjdk.org Wed Aug 17 12:44:17 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Aug 2022 12:44:17 GMT Subject: RFR: JDK-8292351: tty should always live In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 05:25:54 GMT, Thomas Stuefe wrote: > I only chose stdout to keep with the standard behavior of VM output. And therein lies the problem of using stderr. How is this going to work with the flags that switch the VM output between stdout and stderr? Will it make any sense? And how it it going to be when the pre-init output goes to stderr, the regular goes to stdout, and then the termination goes to stderr again? Really you are introducing a new logging destination only used pre-init and post-termination, but pretending it is the regular "tty" output when it isn't. I think the better solution is to expand the usability window of the tty by deferring its shutdown as long as possible. There should be minimal stuff happening before argument processing so not really anything to "log" at that time. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From duke at openjdk.org Wed Aug 17 12:46:43 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 17 Aug 2022 12:46:43 GMT Subject: RFR: 8292446: Make TableRateStatistics optional in CHT [v2] In-Reply-To: References: Message-ID: > Right now the footprint of disabling statistics for tables where they're not used is minimal as they're single instance and static. We're working on using CHT in more contexts, where it will be dynamically allocated, and then these changes will add up to something more substantial. Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: - Uninitialized pointers do not default to nullptr - Fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9899/files - new: https://git.openjdk.org/jdk/pull/9899/files/012e001a..79ea2602 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9899&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9899&range=00-01 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9899.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9899/head:pull/9899 PR: https://git.openjdk.org/jdk/pull/9899 From coleenp at openjdk.org Wed Aug 17 12:54:17 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 17 Aug 2022 12:54:17 GMT Subject: RFR: 8292384: Convert AdapterHandlerTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 16:04:12 GMT, Coleen Phillimore wrote: >> The adapter handler table was a Hashtable, and has been converted to Resourcehashtable, without any complications. >> Tested with tier1-3 (4-7) previously with other changes. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove the mtCode Hashtable instantiations. Thanks Robbin! ------------- PR: https://git.openjdk.org/jdk/pull/9885 From coleenp at openjdk.org Wed Aug 17 12:55:42 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 17 Aug 2022 12:55:42 GMT Subject: Integrated: 8292384: Convert AdapterHandlerTable to ResourceHashtable In-Reply-To: References: Message-ID: <2nbUA4cS9JxBJlPXJn6Ldnx0PsBIS8BjiV-0Q7Kq2Ns=.611c93aa-4e92-453a-91f0-4b28c33d422c@github.com> On Tue, 16 Aug 2022 02:14:41 GMT, Coleen Phillimore wrote: > The adapter handler table was a Hashtable, and has been converted to Resourcehashtable, without any complications. > Tested with tier1-3 (4-7) previously with other changes. This pull request has now been integrated. Changeset: f45b8408 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/f45b8408a0e66aee22a6ac60e3f24dfc8ac104e5 Stats: 199 lines in 3 files changed: 21 ins; 114 del; 64 mod 8292384: Convert AdapterHandlerTable to ResourceHashtable Reviewed-by: hseigel, rehn ------------- PR: https://git.openjdk.org/jdk/pull/9885 From dholmes at openjdk.org Wed Aug 17 13:05:31 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Aug 2022 13:05:31 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: <_S9kQ9tERdyaDhx4uRln5RqhOwNybDYJh8-Clso4OzA=.50ed9ac7-439d-4093-b1c6-5f3c3935a6a5@github.com> On Tue, 16 Aug 2022 19:51:04 GMT, Kim Barrett wrote: > HotSpot Mutex has a rank, True, but I would put the read/write lock in the same basket as Semaphore, being completely independent of Mutex/Monitor. The onus is on the user to use them with care. A shared ranking mechanism would be tricky I think, and read locks don't fit well with ranking schemes. > src/hotspot/share/runtime/mrswMutex.hpp line 63: > >> 61: Locker(T* lock) >> 62: : _lock(lock) { >> 63: if (_lock != nullptr) { > > When would it ever make sense for the `lock` argument to be nullptr? Instead assert in the constructor that it is not? It would make sense in the same circumstances the MutexLocker also takes a NULL argument. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From duke at openjdk.org Wed Aug 17 13:20:15 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 17 Aug 2022 13:20:15 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 20:19:59 GMT, Kim Barrett wrote: >How does it compare with, for example, Terekhov's algorithm? I'm not familiar with this algorithm, do you have a link? >What is the source of the algorithm being used here? I'll have to defer to @fisk for this question. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From dholmes at openjdk.org Wed Aug 17 13:20:15 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Aug 2022 13:20:15 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 18:51:57 GMT, Kim Barrett wrote: > For what it's worth, C++ Standard Library uses "mutex" to refer to an object that gets locked, and uses "lock" to refer to an RAII object that locks a "mutex". So their "lock" would be our MutexLocker? The far more dominant terminology is that a mutex is a lock. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From duke at openjdk.org Wed Aug 17 13:20:17 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 17 Aug 2022 13:20:17 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 04:48:50 GMT, David Holmes wrote: >Are you saying that this is truly restricted to only a single thread being allowed to use this in write mode, rather than just the normal one-writer-at-a-time? The comment was wrong, it's just the regular 1-writer-at-a-time. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From stuefe at openjdk.org Wed Aug 17 13:33:09 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 17 Aug 2022 13:33:09 GMT Subject: RFR: JDK-8292351: tty should always live In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 12:42:09 GMT, David Holmes wrote: > > I only chose stdout to keep with the standard behavior of VM output. > > And therein lies the problem of using stderr. How is this going to work with the flags that switch the VM output between stdout and stderr? Will it make any sense? And how it it going to be when the pre-init output goes to stderr, the regular goes to stdout, and then the termination goes to stderr again? > > Really you are introducing a new logging destination only used pre-init and post-termination, but pretending it is the regular "tty" output when it isn't. Yes. Because that is still better than what we do now. We crash. Before VM init, depending on whether a signal handler is active (custom launchers) with more or less fanfare. In the standard java launcher accessing tty before VM init leads to a single taciturn "Code dumped", which will go to stderr. Or directly to tty, depending on the system. VMs that crash without a trace are a plague, especially in cloud scenarios where you have little to none diagnostic possibilities. Printing to stderr is better than crashing. It is the expected behavior. It is what the C-Runtime and other system libraries do when encountering errors. If we corrupt the stack, for instance. I cannot think of a single scenario where a vanishing or core-ing JVM is better than one that prints its message to stderr. And yes, I create a second "tty", since that allows us to use the same stream object all over the VM while being oblivious about the Life stage the VM is in. The alternative would be to create a second tty, "tty_safe" or similar, and sprinkle conditional coding all over the code base. That is not feasible, apart from being hideous. > > I think the better solution is to expand the usability window of the tty by deferring its shutdown as long as possible. > There should be minimal stuff happening before argument processing so not really anything to "log" at that time. Plain not true. At least not for me, otherwise I would not have bothered with this RFR. I know that I have been in situations where I needed tty and did not use it since it was not yet initialized. NMT preinit system is just one example. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Wed Aug 17 13:53:22 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 17 Aug 2022 13:53:22 GMT Subject: RFR: JDK-8292351: tty should always live [v4] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 09:30:48 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Change comment The problem I have with extending tty's life to beyond VM destruction is that tty is defaultStream and defaultStream is not simple. Just look at defaultStream.write, I find it not easy to decide whether all of this is safe (e.g. using tty_lock) after the VM shut down. Then, you want the destructor of defaultStream to run during VM destruction, since we want the flush. After VM destruction, I want simple unbuffered IO for any subsequent messages. Keep it simple and stupid. If you think using stderr is such a problem for *unplanned* tty output, then we could just assign tty either 1 or 2 depending on the arguments that are now, at the end of VM life, available. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From aboldtch at openjdk.org Wed Aug 17 14:13:08 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 17 Aug 2022 14:13:08 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v5] In-Reply-To: References: Message-ID: > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Add list optimization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9655/files - new: https://git.openjdk.org/jdk/pull/9655/files/2be7b152..bea67dea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=03-04 Stats: 65 lines in 3 files changed: 50 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From stuefe at openjdk.org Wed Aug 17 14:28:19 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 17 Aug 2022 14:28:19 GMT Subject: RFR: JDK-8292351: tty should always live [v4] In-Reply-To: References: Message-ID: <3_GQfkIv9-dQYbyFpG3SyWFU7jqz7R4EXv-Vda6pK40=.1109f7ae-a4c5-40b3-a20b-0d084a22bffb@github.com> On Wed, 17 Aug 2022 09:30:48 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Change comment After looking at `VMError::report_and_die`, I see we redirect error output in case of a crash to hard-wired stdout, we don't use tty. Before this patch, if we accessed tty after VM destruction, we would have printed an error report to stdout. Therefore my initial patch, using stdout hard-wired, was correct and would not have broken compatibility. The only difference would have been that instead of writing a useless "SIGSEGV" crash report to stdout we would have written a useful message to stdout. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From coleenp at openjdk.org Wed Aug 17 15:24:21 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 17 Aug 2022 15:24:21 GMT Subject: RFR: 8292446: Make TableRateStatistics optional in CHT [v2] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 12:46:43 GMT, Johan Sj?l?n wrote: >> Right now the footprint of disabling statistics for tables where they're not used is minimal as they're single instance and static. We're working on using CHT in more contexts, where it will be dynamically allocated, and then these changes will add up to something more substantial. >> >> Passes tier1. > > Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: > > - Uninitialized pointers do not default to nullptr > - Fixes Thank you for doing this. I have a couple small comments. src/hotspot/share/gc/g1/g1CardSet.cpp line 37: > 35: #include "runtime/java.hpp" > 36: #include "utilities/bitMap.inline.hpp" > 37: #include "utilities/concurrentHashTable.hpp" Do you needs this? Doesn't concurrentHashTable.inline.hpp include it already? src/hotspot/share/utilities/concurrentHashTable.hpp line 46: > 44: private: > 45: // _stats_rate is null if statistics are not enabled. > 46: TableRateStatistics* _stats_rate = nullptr; Don't you have to initialize this in the constructor? src/hotspot/share/utilities/concurrentHashTable.hpp line 399: > 397: size_t grow_hint = DEFAULT_GROW_HINT, > 398: void* context = nullptr, > 399: bool enable_statistics = DEFAULT_ENABLE_STATISTICS); I wonder if it would be better to put context last since it's only used by one hashtable? ------------- PR: https://git.openjdk.org/jdk/pull/9899 From coleenp at openjdk.org Wed Aug 17 16:39:06 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 17 Aug 2022 16:39:06 GMT Subject: RFR: 8292556: Clean up unused Hashtable instantiations Message-ID: These instantiations in hashtable.cpp are now unused. Tested with tier1 on Oracle supported platforms. ------------- Commit messages: - 8292556: Clean up unused Hashtable instantiations Changes: https://git.openjdk.org/jdk/pull/9907/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9907&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292556 Stats: 22 lines in 1 file changed: 2 ins; 18 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9907/head:pull/9907 PR: https://git.openjdk.org/jdk/pull/9907 From hseigel at openjdk.org Wed Aug 17 16:56:20 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Wed, 17 Aug 2022 16:56:20 GMT Subject: RFR: 8292556: Clean up unused Hashtable instantiations In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 16:29:30 GMT, Coleen Phillimore wrote: > These instantiations in hashtable.cpp are now unused. Tested with tier1 on Oracle supported platforms. LGTM! Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.org/jdk/pull/9907 From phh at openjdk.org Wed Aug 17 17:28:16 2022 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 17 Aug 2022 17:28:16 GMT Subject: RFR: 8280152: AArch64: Reuse runtime call trampolines [v8] In-Reply-To: <6l5CGvjJBPLBQ15i4GmzNZIQHjDNW6ApSL1nVuulsqM=.9cb03a06-0ab7-4dc1-88fe-a95cac99be7c@github.com> References: <2Rz88X0uWMdi7N4NFC36ZiMXgOhUmh0XehnaOKo6JWM=.9422ee14-4e73-47a5-a211-842fa5331391@github.com> <6l5CGvjJBPLBQ15i4GmzNZIQHjDNW6ApSL1nVuulsqM=.9cb03a06-0ab7-4dc1-88fe-a95cac99be7c@github.com> Message-ID: <3CCqp8xOTOp9v0ODbiB16jXjIRuDJtFPrx98ElJD3YI=.bd79ee00-74f9-4987-bcf3-158a35fac3c5@github.com> On Tue, 16 Aug 2022 04:56:34 GMT, Yi-Fan Tsai wrote: >> A trampoline stub could be generated for each runtime call. These trampolines could be duplication if the callees are the same. This change delays the stub generation and generates one stub for a distinct callee. >> >> Benchmark als, chi-square, dec-tree, gauss-mix, log-regression, movie-lens, naive-bayes, page-rank, fj-means, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~4.7% reduction on average. > > Yi-Fan Tsai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge branch 'master' of https://github.com/yftsai/jdk into JDK-8280152 > - Grow hashtable only if a new entry is added > - Merge branch 'master' of https://github.com/yftsai/jdk into JDK-8280152 > - Reduce maximum hash table size and cleanup > - Use ResizeableResourceHashtable > - Use a hash table to deduplicate > - Rename variables > - Remove dead codes > - Reuse runtime call trampolines There may be a race in initializing _shared_trampoline_requests in codeBuffer_aarch64.cpp with multiple compiler threads. Please investigate and file a JBS issue if so. Lgtm for now. ------------- Marked as reviewed by phh (Reviewer). PR: https://git.openjdk.org/jdk/pull/9405 From svkamath at openjdk.org Wed Aug 17 17:35:39 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Wed, 17 Aug 2022 17:35:39 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v2] In-Reply-To: References: Message-ID: > 8289552: Make intrinsic conversions between bit representations of half precision values and floats Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Added a jmh microbenchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9781/files - new: https://git.openjdk.org/jdk/pull/9781/files/d04fb405..bcbc2f56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=00-01 Stats: 96 lines in 1 file changed: 96 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9781.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781 PR: https://git.openjdk.org/jdk/pull/9781 From svkamath at openjdk.org Wed Aug 17 17:36:53 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Wed, 17 Aug 2022 17:36:53 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 16:36:23 GMT, Smita Kamath wrote: > 8289552: Make intrinsic conversions between bit representations of half precision values and floats JMH results Before patch Benchmark (TESTSIZE) Mode Cnt Score Error Units Fp16ConversionBenchmark.float16ToFloat 2048 thrpt 3 359.680 ? 0.292 ops/ms Fp16ConversionBenchmark.floatToFloat16 2048 thrpt 3 236.153 ? 8.164 ops/ms After patch Benchmark (TESTSIZE) Mode Cnt Score Error Units Fp16ConversionBenchmark.float16ToFloat 2048 thrpt 3 1046.233 ? 0.019 ops/ms Fp16ConversionBenchmark.floatToFloat16 2048 thrpt 3 1752.046 ? 0.058 ops/ms ------------- PR: https://git.openjdk.org/jdk/pull/9781 From duke at openjdk.org Wed Aug 17 17:38:44 2022 From: duke at openjdk.org (Yi-Fan Tsai) Date: Wed, 17 Aug 2022 17:38:44 GMT Subject: Integrated: 8280152: AArch64: Reuse runtime call trampolines In-Reply-To: <2Rz88X0uWMdi7N4NFC36ZiMXgOhUmh0XehnaOKo6JWM=.9422ee14-4e73-47a5-a211-842fa5331391@github.com> References: <2Rz88X0uWMdi7N4NFC36ZiMXgOhUmh0XehnaOKo6JWM=.9422ee14-4e73-47a5-a211-842fa5331391@github.com> Message-ID: <-4Ubluo20UPbcX9gyq_rQ-Lklva4oREKw1MfAv_nDX0=.2352a7e6-9a68-4c3d-8807-47b08c4239cc@github.com> On Thu, 7 Jul 2022 04:10:57 GMT, Yi-Fan Tsai wrote: > A trampoline stub could be generated for each runtime call. These trampolines could be duplication if the callees are the same. This change delays the stub generation and generates one stub for a distinct callee. > > Benchmark als, chi-square, dec-tree, gauss-mix, log-regression, movie-lens, naive-bayes, page-rank, fj-means, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~4.7% reduction on average. This pull request has now been integrated. Changeset: 494d3873 Author: Yi-Fan Tsai Committer: Paul Hohensee URL: https://git.openjdk.org/jdk/commit/494d3873b1d0f7e3ca0a063b44362e7242298dec Stats: 191 lines in 5 files changed: 186 ins; 0 del; 5 mod 8280152: AArch64: Reuse runtime call trampolines Reviewed-by: aph, phh ------------- PR: https://git.openjdk.org/jdk/pull/9405 From coleenp at openjdk.org Wed Aug 17 17:39:21 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 17 Aug 2022 17:39:21 GMT Subject: RFR: 8292556: Clean up unused Hashtable instantiations In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 16:29:30 GMT, Coleen Phillimore wrote: > These instantiations in hashtable.cpp are now unused. Tested with tier1 on Oracle supported platforms. Thanks Harold! ------------- PR: https://git.openjdk.org/jdk/pull/9907 From psandoz at openjdk.org Wed Aug 17 18:00:20 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 17 Aug 2022 18:00:20 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v2] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 17:35:39 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Added a jmh microbenchmark test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 38: > 36: > 37: @Param({"2048"}) > 38: public int TESTSIZE; Suggestion: public int size; test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 40: > 38: public int TESTSIZE; > 39: > 40: public short[] HFargV1; Let's use `F16` instead of `HF`. e.g. f16in, f16out, fin, fout. test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 59: > 57: Random r = new Random(1024); > 58: > 59: HFargV1 = new short[TESTSIZE]; If the test size is less than the number of special values then we will get an exception. I cannot quite decide if special values are that important here. Might be better to test separately? test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 85: > 83: @Benchmark > 84: public void floatToFloat16() { > 85: for (int i = 0; i < TESTSIZE; i++) { Use the array length instead, it's more idiomatic e.g.: Suggestion: for (int i = 0; i < FargV1.length; i++) { test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 88: > 86: ResHF[i] = Float.floatToFloat16(FargV1[i]); > 87: } > 88: } Return the result array, so it's consumed by a black hole. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From vlivanov at openjdk.org Wed Aug 17 18:18:36 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 17 Aug 2022 18:18:36 GMT Subject: RFR: 8292203: AArch64: Represent Registers as values [v3] In-Reply-To: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> Message-ID: > (It's a PR dependent on #9815.) > > Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation. > > The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types. > > Proposed change hides pointer representation behind value class. > > Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). > > Code quality improves: > GCC: https://godbolt.org/z/r6G36facj > Clang: https://godbolt.org/z/x5oPdYEPM > > (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) > > Testing: hs-tier1 - hs-tier5 > > PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: explicit constructors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9826/files - new: https://git.openjdk.org/jdk/pull/9826/files/a139bc03..d0ae344d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9826&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9826&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9826.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9826/head:pull/9826 PR: https://git.openjdk.org/jdk/pull/9826 From vlivanov at openjdk.org Wed Aug 17 18:29:20 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 17 Aug 2022 18:29:20 GMT Subject: RFR: 8292203: AArch64: Represent Registers as values [v2] In-Reply-To: References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> Message-ID: On Mon, 15 Aug 2022 10:26:07 GMT, Quan Anh Mai wrote: >> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - Merge branch 'master' into rwrapper.aarch64 >> - 8292203: AArch64: Represent Registers as values >> - cleanups >> - x86: Register class wrappers > > src/hotspot/cpu/aarch64/register_aarch64.hpp line 39: > >> 37: int _encoding; >> 38: >> 39: constexpr Register(int encoding, bool unused) : _encoding(encoding) {} > > Why do we need unused here? If the intention is to prevent implicit conversion from `int` to `Register` then you can mark the constructor as `explicit`. Thanks. Good point. Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/9826 From stuefe at openjdk.org Wed Aug 17 18:33:17 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 17 Aug 2022 18:33:17 GMT Subject: RFR: JDK-8292351: tty should always live [v4] In-Reply-To: References: Message-ID: <8pGLO_hI9eEE1067idvCxzOWvPttPJ8RLuYCo1HNEyU=.505c3875-4446-4116-81db-90cc18bf979b@github.com> On Wed, 17 Aug 2022 09:30:48 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Change comment (I'm spending way to much time on this) Here is the compatibility situation wrt tty=NULL before and after my patch. - Writing to tty before VM initialization: - Before patch: - Standard java launcher: results in a core dump. More or less silent VM death. We *may* see "Segmentation Fault" if parent process is a shell, on the shell's stderr; text may work its way via the shell's stderr stream into log files. - If custom launcher, and custom launcher installed its own signal handlers, the SIGSEGV will be catched by that handler. All bets are open. But most handlers I have seen just abort the VM on SIGSEGV, finger-pointing to the "broken" Java VM. - After patch: We see the message the calling code intended to send on stderr. - Writing to tty after VM cleanup - Before the patch: Will result in an error report written to *stdout* (not tty), and a hs-err file. The hs-err file will be broken in many places by secondary crashes since error handling also uses tty and does not check if it is valid. Highly likely we will exceed the max. number of secondary crashes and just abort the error handling. - After the patch: We see the message the calling code intended to send on stderr. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From vlivanov at openjdk.org Wed Aug 17 18:33:54 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 17 Aug 2022 18:33:54 GMT Subject: RFR: 8292203: AArch64: Represent Registers as values [v4] In-Reply-To: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> Message-ID: > (It's a PR dependent on #9815.) > > Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation. > > The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types. > > Proposed change hides pointer representation behind value class. > > Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). > > Code quality improves: > GCC: https://godbolt.org/z/r6G36facj > Clang: https://godbolt.org/z/x5oPdYEPM > > (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) > > Testing: hs-tier1 - hs-tier5 > > PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. Vladimir Ivanov 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 rwrapper.aarch64 - explicit constructors - Merge branch 'master' into rwrapper.aarch64 - 8292203: AArch64: Represent Registers as values - cleanups - x86: Register class wrappers ------------- Changes: https://git.openjdk.org/jdk/pull/9826/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9826&range=03 Stats: 527 lines in 15 files changed: 121 ins; 53 del; 353 mod Patch: https://git.openjdk.org/jdk/pull/9826.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9826/head:pull/9826 PR: https://git.openjdk.org/jdk/pull/9826 From vlivanov at openjdk.org Wed Aug 17 19:42:50 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 17 Aug 2022 19:42:50 GMT Subject: RFR: 8292564: x86: Remove redundant casts in Assembler usages Message-ID: Clean up Assembler API and remove redundant at use sites. They are not needed anymore because implicit casts between Register and integrals are forbidden now. Some of the casts are turned into `static_cast`s to assert that constants are small enough to fit into 32-bit immediate. Testing: hs-tier1 - hs-tier4 ------------- Commit messages: - Merge branch 'master' into cast.cleanup - CardTable - Initial Changes: https://git.openjdk.org/jdk/pull/9909/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9909&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292564 Stats: 167 lines in 23 files changed: 0 ins; 35 del; 132 mod Patch: https://git.openjdk.org/jdk/pull/9909.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9909/head:pull/9909 PR: https://git.openjdk.org/jdk/pull/9909 From iveresov at openjdk.org Wed Aug 17 22:18:26 2022 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 17 Aug 2022 22:18:26 GMT Subject: RFR: 8292564: x86: Remove redundant casts in Assembler usages In-Reply-To: References: Message-ID: <_7f4VzotqEcdI3xtgWlyRZI4o0ll8dKuSdHWh2cgQp0=.a1a5a49c-b79a-45bb-966b-27ca8544efa1@github.com> On Wed, 17 Aug 2022 19:29:18 GMT, Vladimir Ivanov wrote: > Clean up Assembler API and remove redundant at use sites. > > They are not needed anymore because implicit casts between Register and integrals are forbidden now. > > Some of the casts are turned into `static_cast`s to assert that constants are small enough to fit into 32-bit immediate. > > Testing: hs-tier1 - hs-tier4 Looks good. ------------- Marked as reviewed by iveresov (Reviewer). PR: https://git.openjdk.org/jdk/pull/9909 From dholmes at openjdk.org Thu Aug 18 02:10:20 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Aug 2022 02:10:20 GMT Subject: RFR: JDK-8292351: tty should always live [v4] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 09:30:48 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Change comment Hi Thomas, Yes this is consuming too much of our time - sorry about that but this does need to be aired. The compatibility issue is not "crash versus no crash", the issue is the ability to add new early/late logging that goes to a fixed destination that the user cannot control and which the existing control flags will not affect. Such logging should be extremely rare (as it by-passes the normal control mechanisms) so making it highly visible in the source code, e.g. by using tty_safe, may not be a bad thing. Code that runs during init, especially very early init, and during termination, is already special code. It has to be independent of all VM services that have not yet started, or may have already terminated. We have often been bitten by code that runs in a context the author had not expected or intended (especially static initializers and destructors) with implicit dependencies that only get exposed when another bug arises (as per the mallocTracker issue). I agree there are issues with determining how far out you can push the stream destruction in the termination process but I still think it may be worth looking into in the context of the current failure. I also note that your code doesn't (and can't?) account for the possibility of races on the use of the tty during termination, so it is still not completely safe. Early VM init could be considered as a separate issue. Really it is only things like NMT that have issues here because you want it enabled (potentially from the initial load of libjvm) but can't use any VM services at that time. We obviously need to have a backup plan for error/crash reporting (as all bets are off by then anyway!), but early logging should be a special case - how do you even turn it on when argument processing has not yet happened? Do we still have that hack to directly read a special environment variable for NMT? So, sorry, but I don't see this as a simple "slam-dunk" issue. But at the end of the day I can only voice my concerns. If other's think this is okay and approve it then so be it. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From xgong at openjdk.org Thu Aug 18 02:24:25 2022 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 18 Aug 2022 02:24:25 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 13:50:29 GMT, Quan Anh Mai wrote: > This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: > > vptest xmm0, xmm1 > jb if_true > if_false: > > instead of: > > vptest xmm0, xmm1 > setb r10 > movzbl r10 > testl r10 > jne if_true > if_false: > > The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: > > Before After > Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change > ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% > > I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. src/hotspot/share/opto/vectorIntrinsics.cpp line 1810: > 1808: } > 1809: Node* cmp = new VectorTestNode(opd1, opd2, booltest); > 1810: cmp = gvn().transform(cmp); Better to merge the two lines into: Node* cmp = gvn().transform(new VectorTestNode(opd1, opd2, booltest)); ------------- PR: https://git.openjdk.org/jdk/pull/9855 From xgong at openjdk.org Thu Aug 18 02:33:32 2022 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 18 Aug 2022 02:33:32 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 13:50:29 GMT, Quan Anh Mai wrote: > This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: > > vptest xmm0, xmm1 > jb if_true > if_false: > > instead of: > > vptest xmm0, xmm1 > setb r10 > movzbl r10 > testl r10 > jne if_true > if_false: > > The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: > > Before After > Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change > ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% > > I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. Please rebase this PR and resolve the conflicts. Then I can have an internal tests for the aarch64 change parts. Thanks a lot! src/hotspot/cpu/aarch64/matcher_aarch64.hpp line 167: > 165: > 166: // Some architecture needs a helper to check for alltrue vector > 167: static bool vectortest_need_second_argument(bool is_alltrue, bool is_predicate) { I think we can get the predicate feature in the backend (i.e. `Matcher::has_predicated_vectors()`), and we do not need the argument here? test/hotspot/jtreg/compiler/vectorapi/TestVectorTest.java line 53: > 51: public int branch(long maskLong) { > 52: var mask = VectorMask.fromLong(ByteVector.SPECIES_PREFERRED, maskLong); > 53: return mask.allTrue() ? call() : 0; Why not use `return mask.allTrue() ? 1 : 0` like the following `cmove`? ------------- PR: https://git.openjdk.org/jdk/pull/9855 From dholmes at openjdk.org Thu Aug 18 02:48:15 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Aug 2022 02:48:15 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10] In-Reply-To: References: Message-ID: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com> On Tue, 16 Aug 2022 10:23:31 GMT, Julian Waters wrote: >> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time >> >> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup src/java.base/unix/native/libjli/java_md_common.c line 213: > 211: */ > 212: char error[1024]; > 213: if(strerror_r(errno, error, sizeof error) == 0) { Style nit: need space after 'if' This applies to other files too. src/java.base/windows/native/libjli/java_md.c line 621: > 619: char *errtext = NULL; > 620: > 621: char* const conflict = "Java detected conflicting Windows and C Runtime errors and is unable to provide an accurate report"; So why not report both of them as part of the message? ------------- PR: https://git.openjdk.org/jdk/pull/9870 From duke at openjdk.org Thu Aug 18 02:50:02 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Thu, 18 Aug 2022 02:50:02 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v2] In-Reply-To: References: Message-ID: > This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: > > vptest xmm0, xmm1 > jb if_true > if_false: > > instead of: > > vptest xmm0, xmm1 > setb r10 > movzbl r10 > testl r10 > jne if_true > if_false: > > The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: > > Before After > Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change > ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% > > I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - redo aarch - Merge branch 'master' into improveVTest - delete aarch64 vector files - copyright - fix condition - fix alltrue - change VectorTest to subclass Cmp - add test - fix aarch build - remove dst in x86.ad - ... and 7 more: https://git.openjdk.org/jdk/compare/0d96546a...cac9948e ------------- Changes: https://git.openjdk.org/jdk/pull/9855/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=01 Stats: 444 lines in 23 files changed: 200 ins; 119 del; 125 mod Patch: https://git.openjdk.org/jdk/pull/9855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9855/head:pull/9855 PR: https://git.openjdk.org/jdk/pull/9855 From duke at openjdk.org Thu Aug 18 02:54:12 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Thu, 18 Aug 2022 02:54:12 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode In-Reply-To: References: Message-ID: <1Dibt0COq1pqcBukSB2yskfVjzPq44htw6QXlq80EpU=.1058e1a5-49b6-45d5-b351-16aa352ffe42@github.com> On Fri, 12 Aug 2022 13:50:29 GMT, Quan Anh Mai wrote: > This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: > > vptest xmm0, xmm1 > jb if_true > if_false: > > instead of: > > vptest xmm0, xmm1 > setb r10 > movzbl r10 > testl r10 > jne if_true > if_false: > > The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: > > Before After > Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change > ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% > > I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. Thanks for your comments, I have redone the patch on top of the new merged aarch file. ------------- PR: https://git.openjdk.org/jdk/pull/9855 From duke at openjdk.org Thu Aug 18 02:54:18 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Thu, 18 Aug 2022 02:54:18 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 02:28:41 GMT, Xiaohong Gong wrote: >> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: >> >> - redo aarch >> - Merge branch 'master' into improveVTest >> - delete aarch64 vector files >> - copyright >> - fix condition >> - fix alltrue >> - change VectorTest to subclass Cmp >> - add test >> - fix aarch build >> - remove dst in x86.ad >> - ... and 7 more: https://git.openjdk.org/jdk/compare/0d96546a...cac9948e > > test/hotspot/jtreg/compiler/vectorapi/TestVectorTest.java line 53: > >> 51: public int branch(long maskLong) { >> 52: var mask = VectorMask.fromLong(ByteVector.SPECIES_PREFERRED, maskLong); >> 53: return mask.allTrue() ? call() : 0; > > Why not use `return mask.allTrue() ? 1 : 0` like the following `cmove`? An non-inline call is to assure that this results in a control flow instead of just a `CMove` node as in the case of the other method. ------------- PR: https://git.openjdk.org/jdk/pull/9855 From duke at openjdk.org Thu Aug 18 02:59:15 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Thu, 18 Aug 2022 02:59:15 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 02:24:16 GMT, Xiaohong Gong wrote: >> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: >> >> - redo aarch >> - Merge branch 'master' into improveVTest >> - delete aarch64 vector files >> - copyright >> - fix condition >> - fix alltrue >> - change VectorTest to subclass Cmp >> - add test >> - fix aarch build >> - remove dst in x86.ad >> - ... and 7 more: https://git.openjdk.org/jdk/compare/0d96546a...cac9948e > > src/hotspot/cpu/aarch64/matcher_aarch64.hpp line 167: > >> 165: >> 166: // Some architecture needs a helper to check for alltrue vector >> 167: static bool vectortest_need_second_argument(bool is_alltrue, bool is_predicate) { > > I think we can get the predicate feature in the backend (i.e. `Matcher::has_predicated_vectors()`), and we do not need the argument here? On AVX3 the availability of predicated vectors does not ensure that every species of vector mask would be translated into predicated vector. To be more specific, although AVX512F returns true for `Matcher::has_predicated_vectors()`, byte and short vector masks required AVX512BW to be translated into predicated vectors and vector masks of < 512-bit species require AVX512VL. ------------- PR: https://git.openjdk.org/jdk/pull/9855 From xgong at openjdk.org Thu Aug 18 03:14:17 2022 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 18 Aug 2022 03:14:17 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 02:55:44 GMT, Quan Anh Mai wrote: >> src/hotspot/cpu/aarch64/matcher_aarch64.hpp line 167: >> >>> 165: >>> 166: // Some architecture needs a helper to check for alltrue vector >>> 167: static bool vectortest_need_second_argument(bool is_alltrue, bool is_predicate) { >> >> I think we can get the predicate feature in the backend (i.e. `Matcher::has_predicated_vectors()`), and we do not need the argument here? > > On AVX3 the availability of predicated vectors does not ensure that every species of vector mask would be translated into predicated vector. To be more specific, although AVX512F returns true for `Matcher::has_predicated_vectors()`, byte and short vector masks required AVX512BW to be translated into predicated vectors and vector masks of < 512-bit species require AVX512VL. OK, I see, thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9855 From duke at openjdk.org Thu Aug 18 03:16:25 2022 From: duke at openjdk.org (Remilia Scarlet) Date: Thu, 18 Aug 2022 03:16:25 GMT Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls In-Reply-To: References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com> Message-ID: On Wed, 17 Aug 2022 12:09:05 GMT, Evgeny Astigeevich wrote: > > Hi @eastig , I'd like to ask you how to get the experiment results, aka. `Saved bytes`, `Nmethods with shared stubs`,`Final # of nmethods`. Thank you! > > You can get `Final # of nmethods` with `-XX:+PrintCodeCache`. To get `Saved bytes`, `Nmethods with shared stubs` you need to instrument `emit_shared_stubs_to_interp` to count shared stubs and nmethods sharing them. Thanks a bunch, eastig. ------------- PR: https://git.openjdk.org/jdk/pull/8816 From xgong at openjdk.org Thu Aug 18 03:22:17 2022 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 18 Aug 2022 03:22:17 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 02:50:02 GMT, Quan Anh Mai wrote: >> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: >> >> vptest xmm0, xmm1 >> jb if_true >> if_false: >> >> instead of: >> >> vptest xmm0, xmm1 >> setb r10 >> movzbl r10 >> testl r10 >> jne if_true >> if_false: >> >> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: >> >> Before After >> Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% >> >> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. > > Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - redo aarch > - Merge branch 'master' into improveVTest > - delete aarch64 vector files > - copyright > - fix condition > - fix alltrue > - change VectorTest to subclass Cmp > - add test > - fix aarch build > - remove dst in x86.ad > - ... and 7 more: https://git.openjdk.org/jdk/compare/0d96546a...cac9948e src/hotspot/share/opto/vectorIntrinsics.cpp line 1810: > 1808: opd2 = opd1; > 1809: } > 1810: Node* cmp = gvn.transform(new VectorTestNode(opd1, opd2, booltest)); should be `gvn()` instead of `gvn` ? ------------- PR: https://git.openjdk.org/jdk/pull/9855 From duke at openjdk.org Thu Aug 18 03:27:25 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Thu, 18 Aug 2022 03:27:25 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v3] In-Reply-To: References: Message-ID: > This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: > > vptest xmm0, xmm1 > jb if_true > if_false: > > instead of: > > vptest xmm0, xmm1 > setb r10 > movzbl r10 > testl r10 > jne if_true > if_false: > > The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: > > Before After > Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change > ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% > > I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9855/files - new: https://git.openjdk.org/jdk/pull/9855/files/cac9948e..c3d18cc9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9855/head:pull/9855 PR: https://git.openjdk.org/jdk/pull/9855 From dholmes at openjdk.org Thu Aug 18 04:39:15 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Aug 2022 04:39:15 GMT Subject: RFR: 8292556: Clean up unused Hashtable instantiations In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 16:29:30 GMT, Coleen Phillimore wrote: > These instantiations in hashtable.cpp are now unused. Tested with tier1 on Oracle supported platforms. LGTM2. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9907 From kvn at openjdk.org Thu Aug 18 05:26:12 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 18 Aug 2022 05:26:12 GMT Subject: RFR: 8292564: x86: Remove redundant casts in Assembler usages In-Reply-To: References: Message-ID: <1_ftI-WZSNGCqjhRMykUWlrHmP7pVoDL0v-riCBFc74=.eba66bc8-9d37-41f4-9141-68767b260988@github.com> On Wed, 17 Aug 2022 19:29:18 GMT, Vladimir Ivanov wrote: > Clean up Assembler API and remove redundant at use sites. > > They are not needed anymore because implicit casts between Register and integrals are forbidden now. > > Some of the casts are turned into `static_cast`s to assert that constants are small enough to fit into 32-bit immediate. > > Testing: hs-tier1 - hs-tier4 Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9909 From duke at openjdk.org Thu Aug 18 05:35:22 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Thu, 18 Aug 2022 05:35:22 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v2] In-Reply-To: References: Message-ID: <8-kyvugUj9twi4eH4ApYGobUqmZKzhaVoq4XAN7-abg=.b66342d4-dc4f-4957-996f-13813eef10a6@github.com> On Thu, 18 Aug 2022 03:18:10 GMT, Xiaohong Gong wrote: >> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: >> >> - redo aarch >> - Merge branch 'master' into improveVTest >> - delete aarch64 vector files >> - copyright >> - fix condition >> - fix alltrue >> - change VectorTest to subclass Cmp >> - add test >> - fix aarch build >> - remove dst in x86.ad >> - ... and 7 more: https://git.openjdk.org/jdk/compare/0d96546a...cac9948e > > src/hotspot/share/opto/vectorIntrinsics.cpp line 1810: > >> 1808: opd2 = opd1; >> 1809: } >> 1810: Node* cmp = gvn.transform(new VectorTestNode(opd1, opd2, booltest)); > > should be `gvn()` instead of `gvn` ? Fixed, the remaining failure in GHA seems to be JDK-8292498 ------------- PR: https://git.openjdk.org/jdk/pull/9855 From stuefe at openjdk.org Thu Aug 18 05:48:14 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 18 Aug 2022 05:48:14 GMT Subject: RFR: JDK-8292351: tty should always live [v4] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 09:30:48 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Change comment Hi David, > Hi Thomas, > > Yes this is consuming too much of our time - sorry about that but this does need to be aired. Sorry for seeming impatient. If there are differences, we have to understand the needs of all and find a good compromise. My experiences may differ from yours since my work revolve(d) a lot around the fringes of the VM - porting, app integration, observability - and in those areas you find yourself often outside the VM life span. > The compatibility issue is not "crash versus no crash"; the issue is the ability to add new early/late logging that goes to a fixed destination that the user cannot control and which the existing control flags will not affect. Such logging should be extremely rare (as it bypasses the normal control mechanisms) so making it highly visible in the source code, e.g. by using tty_safe, may not be a bad thing. Code that runs during init, especially very early init, and during termination, is already a special code. It has to be independent of all VM services that have not yet started or may have already terminated. We have often been bitten by code that runs in a context the author had not expected or intended (especially static initializers and destructors) with implicit dependencies that only get exposed when another bug arises (as per the mallocTracker issue). I think the difference between us is what we consider worse. For us, vanishing VMs are really bad since we usually have no or no easy access to the situation, and log files are our only tool. That is why we were so intent on hardening out error reporting. So I usually consider any output important and like to see it. That said, I can see that unimportant tty output getting stuck in the middle of log files can cause grief since parsers would get thrown off. We also have experienced that. > > I agree there are issues with determining how far out you can push the stream destruction in the termination process but I still think it may be worth looking into in the context of the current failure. I also note that your code doesn't (and can't?) account for the possibility of races on the use of the tty during termination, so it is still not completely safe. We can look into extending the lifespan of defaultStream, but before that, I'd like to check if this is even needed. defaultStream is surprisingly complex - it inherits from xmlStream for some reason and seems to have ties to the compiler, etc. I'm also worried about bitrot here, even if it is today safe to use, it may not be tomorrow if someone changes it. So we not only need to check, simplify, and potentially fix it, we also need guards against regressions. For this patch, I'm aiming for a minimally invasive patch here that is also easy to downport. About races, that one is true. If someone concurrently uses tty while it gets destroyed, we will crash. My patch does not help here. > > Early VM init could be considered as a separate issue. Really it is only things like NMT that have issues here because you want it enabled (potentially from the initial load of libjvm) but can't use any VM services at that time. You would be surprised how much code is running before VM initialization via C++ dynamic initialization. Mostly UL and Compiler-related. That was the reason why we needed NMT preinit - because there were a lot of calls to os::malloc before initialization. I really dislike this since it randomizes initialization order and makes debugging very complicated. But it is what it is. > We obviously need to have a backup plan for error/crash reporting (as all bets are off by then anyway!), but early logging should be a special case - how do you even turn it on when argument processing has not yet happened? Do we still have that hack to directly read a special environment variable for NMT? Oh, no. That was the whole reason for the NMT rewrite https://bugs.openjdk.org/browse/JDK-8256844. It made NMT late-initializable and usable in custom launchers (e.g. also during gtests). But for that, it needs some early magic to deal with above mentioned early os::malloc calls. > > So, sorry, but I don't see this as a simple "slam-dunk" issue. But at the end of the day, I can only voice my concerns. If others think this is okay and approve it then so be it. How about a compromise then? I consider post-VM-exit the more important part. And also the more likely to fail. Here the process has a "VM history" that may cause code to access tty. For example, the NMT C-Heap corruption checker you encountered. Or things like error handling: We don't disable the signal handlers so that we will handle crashes till the bitter end. And things like AGCT, which unfortunately exist. So, how about - Pre init: We silently swallow all output to tty without crashing. But we give the user a way to switch output on via environment variable (that is really the only way before arg parsing), e.g. "VM_ENABLE_EARLY_TTY". If that is set, we set tty to stdout. - Post exit: We extend the lifespan of tty "in spirit": after exit, we assign tty either to stdout or stderr, depending on what option the user had set. We default to stdout, since that is where todays tty=NULL crashes would have been written to. That would preserve the final defaultStream flush and make sure any subsequent output is written immediately since its unbuffered. In the future, we can clean up and simplify defaultStream, make it work beyond the VM lifespan, and add regression checks for this. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/9874 From xgong at openjdk.org Thu Aug 18 06:35:18 2022 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 18 Aug 2022 06:35:18 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v3] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 03:27:25 GMT, Quan Anh Mai wrote: >> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: >> >> vptest xmm0, xmm1 >> jb if_true >> if_false: >> >> instead of: >> >> vptest xmm0, xmm1 >> setb r10 >> movzbl r10 >> testl r10 >> jne if_true >> if_false: >> >> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: >> >> Before After >> Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% >> >> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > fix Tests pass on aarch64 NEON and SVE. So aarch64 part looks good to me. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9855 From xgong at openjdk.org Thu Aug 18 06:37:45 2022 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 18 Aug 2022 06:37:45 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 02:50:02 GMT, Quan Anh Mai wrote: >> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: >> >> vptest xmm0, xmm1 >> jb if_true >> if_false: >> >> instead of: >> >> vptest xmm0, xmm1 >> setb r10 >> movzbl r10 >> testl r10 >> jne if_true >> if_false: >> >> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: >> >> Before After >> Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% >> >> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. > > Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - redo aarch > - Merge branch 'master' into improveVTest > - delete aarch64 vector files > - copyright > - fix condition > - fix alltrue > - change VectorTest to subclass Cmp > - add test > - fix aarch build > - remove dst in x86.ad > - ... and 7 more: https://git.openjdk.org/jdk/compare/0d96546a...cac9948e src/hotspot/cpu/aarch64/aarch64_vector.ad line 5766: > 5764: predicate(UseSVE == 0 && > 5765: static_cast(n)->get_predicate() == BoolTest::ne); > 5766: match(Set cr (VectorTest src1 src2 )); style: please remove the space between `src2 )` ------------- PR: https://git.openjdk.org/jdk/pull/9855 From haosun at openjdk.org Thu Aug 18 06:55:17 2022 From: haosun at openjdk.org (Hao Sun) Date: Thu, 18 Aug 2022 06:55:17 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v3] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 03:27:25 GMT, Quan Anh Mai wrote: >> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: >> >> vptest xmm0, xmm1 >> jb if_true >> if_false: >> >> instead of: >> >> vptest xmm0, xmm1 >> setb r10 >> movzbl r10 >> testl r10 >> jne if_true >> if_false: >> >> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: >> >> Before After >> Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% >> >> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > fix src/hotspot/cpu/aarch64/aarch64_vector.ad line 5763: > 5761: // anytrue > 5762: > 5763: instruct vtest_anytrue_neon(rFlagsReg cr, vReg src1, vReg src2, iRegINoSp tmp, vReg vtmp) %{ I think we can simply use `rscratch1` here instead of introducing one temp reg. src/hotspot/cpu/aarch64/aarch64_vector.ad line 5794: > 5792: // alltrue > 5793: > 5794: instruct vtest_alltrue_neon(rFlagsReg cr, vReg src1, vReg src2, iRegINoSp tmp, vReg vtmp) %{ Similar to `vtest_anytrue_neon` rule, we can use `rscratch1` here. ------------- PR: https://git.openjdk.org/jdk/pull/9855 From xgong at openjdk.org Thu Aug 18 06:55:18 2022 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 18 Aug 2022 06:55:18 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v3] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 03:27:25 GMT, Quan Anh Mai wrote: >> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: >> >> vptest xmm0, xmm1 >> jb if_true >> if_false: >> >> instead of: >> >> vptest xmm0, xmm1 >> setb r10 >> movzbl r10 >> testl r10 >> jne if_true >> if_false: >> >> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: >> >> Before After >> Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% >> >> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > fix src/hotspot/share/opto/vectorIntrinsics.cpp line 1808: > 1806: if (!Matcher::vectortest_needs_second_argument(booltest == BoolTest::overflow, opd1->bottom_type()->isa_vectmask())) { > 1807: opd2 = opd1; > 1808: } How about floating up this under line-1801, like: Node* opd2 = NULL; if (!Matcher::vectortest_needs_second_argument(...)) { opd2 = opd1; } else { opd2 = unbox_vector(argument(5), ...); } if (opd1 == NULL || opd2 == NULL) { return false; } This can avoid the unnecessary vector unbox to `argument(5)` if the platform doesn't need opd2 during codegen. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9855 From xgong at openjdk.org Thu Aug 18 07:00:21 2022 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 18 Aug 2022 07:00:21 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v3] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 03:27:25 GMT, Quan Anh Mai wrote: >> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: >> >> vptest xmm0, xmm1 >> jb if_true >> if_false: >> >> instead of: >> >> vptest xmm0, xmm1 >> setb r10 >> movzbl r10 >> testl r10 >> jne if_true >> if_false: >> >> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: >> >> Before After >> Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% >> >> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > fix src/hotspot/share/opto/vectornode.hpp line 1437: > 1435: virtual uint hash() const { return Node::hash() + _predicate; } > 1436: virtual const Type* Value(PhaseGVN* phase) const { return TypeInt::CC; } > 1437: virtual const Type *sub( const Type *, const Type * ) const { return TypeInt::CC; } style: suggest to change to: virtual const Type* sub(const Type*, const Type*) ------------- PR: https://git.openjdk.org/jdk/pull/9855 From duke at openjdk.org Thu Aug 18 07:34:13 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Thu, 18 Aug 2022 07:34:13 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v4] In-Reply-To: References: Message-ID: > This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: > > vptest xmm0, xmm1 > jb if_true > if_false: > > instead of: > > vptest xmm0, xmm1 > setb r10 > movzbl r10 > testl r10 > jne if_true > if_false: > > The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: > > Before After > Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change > ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% > > I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: style + use rscratch instead of tmp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9855/files - new: https://git.openjdk.org/jdk/pull/9855/files/c3d18cc9..14b71c00 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=02-03 Stats: 34 lines in 4 files changed: 6 ins; 3 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/9855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9855/head:pull/9855 PR: https://git.openjdk.org/jdk/pull/9855 From duke at openjdk.org Thu Aug 18 07:34:16 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Thu, 18 Aug 2022 07:34:16 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v3] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 03:27:25 GMT, Quan Anh Mai wrote: >> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: >> >> vptest xmm0, xmm1 >> jb if_true >> if_false: >> >> instead of: >> >> vptest xmm0, xmm1 >> setb r10 >> movzbl r10 >> testl r10 >> jne if_true >> if_false: >> >> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: >> >> Before After >> Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% >> >> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > fix I have resolved your comments, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9855 From xgong at openjdk.org Thu Aug 18 07:36:52 2022 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 18 Aug 2022 07:36:52 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v4] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 07:34:13 GMT, Quan Anh Mai wrote: >> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: >> >> vptest xmm0, xmm1 >> jb if_true >> if_false: >> >> instead of: >> >> vptest xmm0, xmm1 >> setb r10 >> movzbl r10 >> testl r10 >> jne if_true >> if_false: >> >> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: >> >> Before After >> Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% >> >> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > style + use rscratch instead of tmp Looks good to me! It also needs others to take a look. Thanks! ------------- Marked as reviewed by xgong (Committer). PR: https://git.openjdk.org/jdk/pull/9855 From haosun at openjdk.org Thu Aug 18 07:47:20 2022 From: haosun at openjdk.org (Hao Sun) Date: Thu, 18 Aug 2022 07:47:20 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v4] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 07:34:13 GMT, Quan Anh Mai wrote: >> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: >> >> vptest xmm0, xmm1 >> jb if_true >> if_false: >> >> instead of: >> >> vptest xmm0, xmm1 >> setb r10 >> movzbl r10 >> testl r10 >> jne if_true >> if_false: >> >> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: >> >> Before After >> Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% >> >> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > style + use rscratch instead of tmp src/hotspot/cpu/aarch64/aarch64_vector.ad line 5763: > 5761: // anytrue > 5762: > 5763: instruct vtest_anytrue_neon(rFlagsReg cr, vReg src1, vReg src2, vReg vtmp) %{ I think we needn't change the name. ------------- PR: https://git.openjdk.org/jdk/pull/9855 From shade at openjdk.org Thu Aug 18 07:53:12 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 18 Aug 2022 07:53:12 GMT Subject: RFR: 8292564: x86: Remove redundant casts in Assembler usages In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 19:29:18 GMT, Vladimir Ivanov wrote: > Some of the casts are turned into `static_cast`s to assert that constants are small enough to fit into 32-bit immediate. This confuses me a bit: I thought narrowing (implicit) conversions with `static_cast` would not assert safety in these cases. We have `checked_cast` for these. ------------- PR: https://git.openjdk.org/jdk/pull/9909 From duke at openjdk.org Thu Aug 18 08:13:15 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Thu, 18 Aug 2022 08:13:15 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v5] In-Reply-To: References: Message-ID: <8T81q19HumlciRk-VTyp_LIwUDKQv5B-H78CYtigk_U=.bfa6af05-4245-4232-82dd-1ab9a4851c1f@github.com> > This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: > > vptest xmm0, xmm1 > jb if_true > if_false: > > instead of: > > vptest xmm0, xmm1 > setb r10 > movzbl r10 > testl r10 > jne if_true > if_false: > > The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: > > Before After > Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change > ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% > > I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: revert renaming temp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9855/files - new: https://git.openjdk.org/jdk/pull/9855/files/14b71c00..5444c51d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=03-04 Stats: 20 lines in 2 files changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/9855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9855/head:pull/9855 PR: https://git.openjdk.org/jdk/pull/9855 From duke at openjdk.org Thu Aug 18 08:13:19 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Thu, 18 Aug 2022 08:13:19 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v4] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 07:43:40 GMT, Hao Sun wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> style + use rscratch instead of tmp > > src/hotspot/cpu/aarch64/aarch64_vector.ad line 5763: > >> 5761: // anytrue >> 5762: >> 5763: instruct vtest_anytrue_neon(rFlagsReg cr, vReg src1, vReg src2, vReg vtmp) %{ > > I think we needn't change the name. Yes I agree, other places use `tmp` for temporary vector registers so I have reverted this. Thanks ------------- PR: https://git.openjdk.org/jdk/pull/9855 From jwaters at openjdk.org Thu Aug 18 08:14:18 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 18 Aug 2022 08:14:18 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10] In-Reply-To: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com> References: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com> Message-ID: On Thu, 18 Aug 2022 02:39:55 GMT, David Holmes wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup > > src/java.base/windows/native/libjli/java_md.c line 621: > >> 619: char *errtext = NULL; >> 620: >> 621: char* const conflict = "Java detected conflicting Windows and C Runtime errors and is unable to provide an accurate report"; > > So why not report both of them as part of the message? I was mainly concerned with Thomas's objection that having both would simply be misleading, though now that you say that, maybe this warning combined with both could be a good compromise. @tstuefe thoughts? ------------- PR: https://git.openjdk.org/jdk/pull/9870 From duke at openjdk.org Thu Aug 18 08:17:18 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Thu, 18 Aug 2022 08:17:18 GMT Subject: RFR: 8292446: Make TableRateStatistics optional in CHT [v2] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 15:16:55 GMT, Coleen Phillimore wrote: >> Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: >> >> - Uninitialized pointers do not default to nullptr >> - Fixes > > src/hotspot/share/utilities/concurrentHashTable.hpp line 46: > >> 44: private: >> 45: // _stats_rate is null if statistics are not enabled. >> 46: TableRateStatistics* _stats_rate = nullptr; > > Don't you have to initialize this in the constructor? My Google-fu fails me in what the difference between this assignment and doing it in the constructor is, so I'm moving it to the constructor to be sure. ------------- PR: https://git.openjdk.org/jdk/pull/9899 From aboldtch at openjdk.org Thu Aug 18 08:18:27 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 18 Aug 2022 08:18:27 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v6] In-Reply-To: References: Message-ID: > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Cleanup comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9655/files - new: https://git.openjdk.org/jdk/pull/9655/files/bea67dea..4b95396c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From pli at openjdk.org Thu Aug 18 08:21:43 2022 From: pli at openjdk.org (Pengfei Li) Date: Thu, 18 Aug 2022 08:21:43 GMT Subject: RFR: 8292511: AArch64: Align CPU feature name for NEON with hwcap Message-ID: AArch64 hwcap uses `asimd` to represent the CPU feature of NEON. But in vm_version_aarch64.hpp, this name is redefined as `simd`. This renaming looks trivial but can easily lead to bugs in test cases as more and more people start writing jtreg IR tests today. For example, if someone just finds CPU feature name from some documents or `/proc/cpuinfo`, and writes below annotations in his test case, the test case won't run on AArch64. - `@requires vm.cpu.features ~= ".*asimd.*"` - `@IR(applyIfCPUFeature = {"asimd", "true"}, counts = {...})` So in this patch we propose to align the CPU feature names. Some related jtreg cases are also updated. There's another misalignment of the names for CPU feature `sha2`. We don't change it as we have some discussions in https://bugs.openjdk.org/browse/JDK-8285266. Tested tier1 and hotspot:compiler/vectorapi on x86 and AArch64. ------------- Commit messages: - 8292511: AArch64: Align CPU feature name for NEON with hwcap Changes: https://git.openjdk.org/jdk/pull/9913/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9913&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292511 Stats: 17 lines in 5 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/9913.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9913/head:pull/9913 PR: https://git.openjdk.org/jdk/pull/9913 From jwaters at openjdk.org Thu Aug 18 08:23:22 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 18 Aug 2022 08:23:22 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v11] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Resolve issues ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/e271f0a8..a9ff11fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=09-10 Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Thu Aug 18 08:25:47 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 18 Aug 2022 08:25:47 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10] In-Reply-To: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com> References: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com> Message-ID: <_3aw2eO_JUJVFZiJImuWcN0cfBcAAfhzrHmt0AAsc_c=.a929046e-bcb8-4c43-8a77-ec1617692ee2@github.com> On Thu, 18 Aug 2022 02:36:37 GMT, David Holmes wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup > > src/java.base/unix/native/libjli/java_md_common.c line 213: > >> 211: */ >> 212: char error[1024]; >> 213: if(strerror_r(errno, error, sizeof error) == 0) { > > Style nit: need space after 'if' > > This applies to other files too. Fixed, thanks for the heads up ------------- PR: https://git.openjdk.org/jdk/pull/9870 From aph at openjdk.org Thu Aug 18 08:28:17 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Aug 2022 08:28:17 GMT Subject: RFR: 8292511: AArch64: Align CPU feature name for NEON with hwcap In-Reply-To: References: Message-ID: <4r4dqLNrokNQccst12maPvRy4TGLTYByugjmxF6taUk=.c4364d36-6141-4dd9-a3f5-e2b30a89350c@github.com> On Thu, 18 Aug 2022 08:13:29 GMT, Pengfei Li wrote: > AArch64 hwcap uses `asimd` to represent the CPU feature of NEON. But in > vm_version_aarch64.hpp, this name is redefined as `simd`. This renaming > looks trivial but can easily lead to bugs in test cases as more and more > people start writing jtreg IR tests today. > > For example, if someone just finds CPU feature name from some documents > or `/proc/cpuinfo`, and writes below annotations in his test case, the > test case won't run on AArch64. > - `@requires vm.cpu.features ~= ".*asimd.*"` > - `@IR(applyIfCPUFeature = {"asimd", "true"}, counts = {...})` > > So in this patch we propose to align the CPU feature names. Some related > jtreg cases are also updated. There's another misalignment of the names > for CPU feature `sha2`. We don't change it as we have some discussions > in https://bugs.openjdk.org/browse/JDK-8285266. > > Tested tier1 and hotspot:compiler/vectorapi on x86 and AArch64. Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9913 From aboldtch at openjdk.org Thu Aug 18 08:55:22 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 18 Aug 2022 08:55:22 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v6] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 08:18:27 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup comment Opening this PR for review. Terminology for deoptimizing compiled methods has been updated and the process encapsulated. The terminology was chosen to better reflect what is happening and not clash with other terminology used when working with compiled methods. The encapsulation was done with a RAII object which enables more rigorous assertion of the usage and behaviour of the code. The fix for the deviation mentioned in the issue and the comments above was address in [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) and has been merged. I made some comments about moving out the linked list optimisation into a separate issue, however there are two tests that currently are sensitive to (I suspect) asserts inside the critical sections of the deoptimization. The tests are: * `vmTestbase/vm/mlvm/indy/stress/java/volatileCallSiteDekker/TestDescription.java` * `vmTestbase/vm/mlvm/indy/stress/java/mutableCallSiteDekker/TestDescription.java` They will (most of the time) timeout on linux debug builds, but succeed with a larger `timeoutFactor`. I do not yet have access to a linux machine to debug and investigate more thoroughly, but I suspect that, as this test just keep rebinding CallSites in a loop, they trigger a lot of deoptimizations which creates a lot of contention on the `Compile_lock` and `CodeCache_lock`, and the longer critical sections (due to more asserts) increase the probability of contention slowdowns. With the bea67de the timeout problem goes away as we are not walking the CodeCache when we do not need to. The unnecessary CodeCache walking time to safepoint issue is what motivated the encapsulation in the first place. __Testing: Oracle Platforms Tier 1-5__ ------------- PR: https://git.openjdk.org/jdk/pull/9655 From stuefe at openjdk.org Thu Aug 18 08:56:17 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 18 Aug 2022 08:56:17 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v11] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 08:23:22 GMT, Julian Waters wrote: >> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time >> >> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Resolve issues src/java.base/unix/native/libjli/java_md_common.c line 213: > 211: */ > 212: char error[1024]; > 213: if (strerror_r(errno, error, sizeof error) == 0) { Please use brackets with sizeof src/java.base/windows/native/libjli/java_md.c line 611: > 609: * Because Windows API errors and regular errno errors can exist at the same time, > 610: * compromise and error out when both are present. Windows code should ideally clear > 611: * the last error before a call that sets either of these! That comment is strange. Of course Windows resets both errno or GetLastError if an API using them is called. But these mechanisms have nothing to do with each other and resetting errno if a WIN32 call is done would be wrong, and vice versa. ------------- PR: https://git.openjdk.org/jdk/pull/9870 From stuefe at openjdk.org Thu Aug 18 08:56:19 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 18 Aug 2022 08:56:19 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10] In-Reply-To: References: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com> Message-ID: On Thu, 18 Aug 2022 08:10:34 GMT, Julian Waters wrote: >> src/java.base/windows/native/libjli/java_md.c line 621: >> >>> 619: char *errtext = NULL; >>> 620: >>> 621: char* const conflict = "Java detected conflicting Windows and C Runtime errors and is unable to provide an accurate report"; >> >> So why not report both of them as part of the message? > > I was mainly concerned with Thomas's objection that having both would simply be misleading, though now that you say that, maybe this warning combined with both could be a good compromise. > > @tstuefe thoughts? Let's back up a bit. I looked again, and think @dholmes-ora was originally right when he wrote that this coding does not get called on Windows. Not sure why I thought differently, but I cannot find a single callsite on windows. But that is weird, since originally there was an error reported on Windows: https://bugs.openjdk.org/browse/JDK-8291917 reported a real problem about windows printing useless error messages. What was the original problem again? If we are right and this code is not needed, I'd just scrap this function on Windows altogether. ------------- PR: https://git.openjdk.org/jdk/pull/9870 From dlong at openjdk.org Thu Aug 18 09:01:15 2022 From: dlong at openjdk.org (Dean Long) Date: Thu, 18 Aug 2022 09:01:15 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v6] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 08:18:27 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup comment src/hotspot/share/code/compiledMethod.cpp line 128: > 126: if (old_status < new_status) { > 127: if (old_status == not_enqueued) { > 128: assert(extract_enqueued_deoptimization_method(_enqueued_deoptimization_link) == nullptr, "Compiled Method should not already be linked"); This doesn't work for the tail of the list, does it? That's why I suggested making the tail loop back to itself. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From duke at openjdk.org Thu Aug 18 09:14:23 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Thu, 18 Aug 2022 09:14:23 GMT Subject: RFR: 8292446: Make TableRateStatistics optional in CHT [v3] In-Reply-To: References: Message-ID: > Right now the footprint of disabling statistics for tables where they're not used is minimal as they're single instance and static. We're working on using CHT in more contexts, where it will be dynamically allocated, and then these changes will add up to something more substantial. > > Passes tier1. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Fix review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9899/files - new: https://git.openjdk.org/jdk/pull/9899/files/79ea2602..e1b322c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9899&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9899&range=01-02 Stats: 11 lines in 6 files changed: 2 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9899.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9899/head:pull/9899 PR: https://git.openjdk.org/jdk/pull/9899 From duke at openjdk.org Thu Aug 18 09:14:26 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Thu, 18 Aug 2022 09:14:26 GMT Subject: RFR: 8292446: Make TableRateStatistics optional in CHT [v2] In-Reply-To: References: Message-ID: <5fp-Se00rp69y7DT7EZemt-RVYhdkFKmk2jHgqwxGeY=.c5d12c1d-ee36-4e41-8657-694a0e2110b5@github.com> On Wed, 17 Aug 2022 15:15:07 GMT, Coleen Phillimore wrote: >> Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: >> >> - Uninitialized pointers do not default to nullptr >> - Fixes > > src/hotspot/share/gc/g1/g1CardSet.cpp line 37: > >> 35: #include "runtime/java.hpp" >> 36: #include "utilities/bitMap.inline.hpp" >> 37: #include "utilities/concurrentHashTable.hpp" > > Do you needs this? Doesn't concurrentHashTable.inline.hpp include it already? Fixed :). > src/hotspot/share/utilities/concurrentHashTable.hpp line 399: > >> 397: size_t grow_hint = DEFAULT_GROW_HINT, >> 398: void* context = nullptr, >> 399: bool enable_statistics = DEFAULT_ENABLE_STATISTICS); > > I wonder if it would be better to put context last since it's only used by one hashtable? That did make things nicer! ------------- PR: https://git.openjdk.org/jdk/pull/9899 From duke at openjdk.org Thu Aug 18 09:22:15 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Thu, 18 Aug 2022 09:22:15 GMT Subject: RFR: 8292446: Make TableRateStatistics optional in CHT [v4] In-Reply-To: References: Message-ID: > Right now the footprint of disabling statistics for tables where they're not used is minimal as they're single instance and static. We're working on using CHT in more contexts, where it will be dynamically allocated, and then these changes will add up to something more substantial. > > Passes tier1. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Declare functions inline ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9899/files - new: https://git.openjdk.org/jdk/pull/9899/files/e1b322c1..8353bbc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9899&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9899&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9899.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9899/head:pull/9899 PR: https://git.openjdk.org/jdk/pull/9899 From aboldtch at openjdk.org Thu Aug 18 09:37:18 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 18 Aug 2022 09:37:18 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v6] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 08:57:19 GMT, Dean Long wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup comment > > src/hotspot/share/code/compiledMethod.cpp line 128: > >> 126: if (old_status < new_status) { >> 127: if (old_status == not_enqueued) { >> 128: assert(extract_enqueued_deoptimization_method(_enqueued_deoptimization_link) == nullptr, "Compiled Method should not already be linked"); > > This doesn't work for the tail of the list, does it? That's why I suggested making the tail loop back to itself > > I would also like to see similar asserts added to make sure we don't recycle an nmethod that is still on the list, perhaps in nmethod::flush(). I think you have to describe the scenario that does not work, because I am not sure I see it. For ease of writing, let me call the currently embedded status `status` and the currently embedded link `next_link` (`=>` means implies here) The assert checks this invariant: `status == not_enqueued => next_link == nullptr` After adding the first method (which will be the tail) to the list (`root == nullptr`) we will have: * `status > not_enqueued` * `next_link == nullptr` After adding any method after that ( `root != nullptr`) we will have: * `status > not_enqueued` * `next_link == previous_root` And there is also a fresh method * `status == not_enqueued` * `next_link == nullptr` If we try to enqueue an already enqueued method (calling `enqueue_deoptimization` twice) the method will have `status != not_enqueued` and will set `next_link == next_link` if `new_status > status`. (So just update the status to a stronger variant, but not change the link) All of these possibilities upholds the invariant. Maybe you are looking for some more invariant checks, like `status > not_enqueued => InList(method)` which can be asserted by setting `next_link == this` for the tail (when `root == nullptr`) and assert that `next_link != nullptr` if `status > not_enqueued`. But it just seems like we are adding another flag for something we already check, essentially `next_link != nullptr` iff `status > not_enqueued`. There is currently an assert when we iterate over the list; that the number of methods we find in the list is equal to number of methods we enqueued. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From jwaters at openjdk.org Thu Aug 18 09:50:16 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 18 Aug 2022 09:50:16 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10] In-Reply-To: References: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com> Message-ID: <92O7ygNu0UfHUfRaFp3KuNQ5PQe3tf2AGmDRXwgwRAg=.641f4e87-9c75-4e2f-8c81-fb9a32372c32@github.com> On Thu, 18 Aug 2022 08:52:36 GMT, Thomas Stuefe wrote: >> I was mainly concerned with Thomas's objection that having both would simply be misleading, though now that you say that, maybe this warning combined with both could be a good compromise. >> >> @tstuefe thoughts? > > Let's back up a bit. > > I looked again, and think @dholmes-ora was originally right when he wrote that this coding does not get called on Windows. Not sure why I thought differently, but I cannot find a single callsite on windows. > > But that is weird, since originally there was an error reported on Windows: https://bugs.openjdk.org/browse/JDK-8291917 reported a real problem about windows printing useless error messages. What was the original problem again? > > If we are right and this code is not needed, I'd just scrap this function on Windows altogether. 8291917 was simply about making error messages more informative on Windows when loading the C Runtime or Java Virtual Machine dlls failed (Right now it just prints an unhelpful "Error: loading: ...") - It consequently depended on this RFE for the functionality. Although it _can_ use the other error reporting utilities the JDK has elsewhere, this one happens to be the most convenient, but a more important reason is that the other utilities provided by the JDK all also use the same flawed logic as this one, if we can decide how to fix this function here and now, we'd be able to extrapolate the solution to those other areas as well with very little fuss, so I think fixing this would be better than simply opting to remove it ------------- PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Thu Aug 18 09:52:37 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 18 Aug 2022 09:52:37 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v12] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Address review concerns ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/a9ff11fa..ff398500 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=10-11 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From stuefe at openjdk.org Thu Aug 18 09:58:10 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 18 Aug 2022 09:58:10 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10] In-Reply-To: <92O7ygNu0UfHUfRaFp3KuNQ5PQe3tf2AGmDRXwgwRAg=.641f4e87-9c75-4e2f-8c81-fb9a32372c32@github.com> References: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com> <92O7ygNu0UfHUfRaFp3KuNQ5PQe3tf2AGmDRXwgwRAg=.641f4e87-9c75-4e2f-8c81-fb9a32372c32@github.com> Message-ID: <7PP7QsJ9FmXSuiWlnM8nahCiLxuQA5rX25WW85Zs504=.a9c44739-e37f-422c-b014-77974d1a69a2@github.com> On Thu, 18 Aug 2022 09:46:56 GMT, Julian Waters wrote: >> Let's back up a bit. >> >> I looked again, and think @dholmes-ora was originally right when he wrote that this coding does not get called on Windows. Not sure why I thought differently, but I cannot find a single callsite on windows. >> >> But that is weird, since originally there was an error reported on Windows: https://bugs.openjdk.org/browse/JDK-8291917 reported a real problem about windows printing useless error messages. What was the original problem again? >> >> If we are right and this code is not needed, I'd just scrap this function on Windows altogether. > > 8291917 was simply about making error messages more informative on Windows when loading the C Runtime or Java Virtual Machine dlls failed (Right now it just prints an unhelpful "Error: loading: ...") - It consequently depended on this RFE for the functionality. Although it _can_ use the other error reporting utilities the JDK has elsewhere, this one happens to be the most convenient, but a more important reason is that the other utilities provided by the JDK all also use the same flawed logic as this one, if we can decide how to fix this function here and now, we'd be able to extrapolate the solution to those other areas as well with very little fuss, so I think fixing this would be better than simply opting to remove it Okay, this is for future use. We don't usually add complexity as a preparation for the future. We usually include usage and functionality in one RFE. That way reviewers can see how the feature is supposed to be used, and whether its worth to keep it. You may hear other opinions, but what I would do: - make an RFE that actually enriches failing Win32 API calls with GetLastError, using the non-sys variant (JLI_ReportErrorMessage) and just manually adding the error code at the call sites. - If that turns out to be many call sites, we can think about adding a windows specific JLI_ReportErrorMessageSysWin32. - If that's just 2-5 sites or so, leave it and just scrap JLI_ReportErrorMessageSys for windows. Just my 5 cent. ------------- PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Thu Aug 18 11:25:19 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 18 Aug 2022 11:25:19 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10] In-Reply-To: <7PP7QsJ9FmXSuiWlnM8nahCiLxuQA5rX25WW85Zs504=.a9c44739-e37f-422c-b014-77974d1a69a2@github.com> References: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com> <92O7ygNu0UfHUfRaFp3KuNQ5PQe3tf2AGmDRXwgwRAg=.641f4e87-9c75-4e2f-8c81-fb9a32372c32@github.com> <7PP7QsJ9FmXSuiWlnM8nahCiLxuQA5rX25WW85Zs504=.a9c44739-e37f-422c-b014-77974d1a69a2@github.com> Message-ID: On Thu, 18 Aug 2022 09:55:59 GMT, Thomas Stuefe wrote: >> 8291917 was simply about making error messages more informative on Windows when loading the C Runtime or Java Virtual Machine dlls failed (Right now it just prints an unhelpful "Error: loading: ...") - It consequently depended on this RFE for the functionality. Although it _can_ use the other error reporting utilities the JDK has elsewhere, this one happens to be the most convenient, but a more important reason is that the other utilities provided by the JDK all also use the same flawed logic as this one, if we can decide how to fix this function here and now, we'd be able to extrapolate the solution to those other areas as well with very little fuss, so I think fixing this would be better than simply opting to remove it > > Okay, this is for future use. We don't usually add complexity as a preparation for the future. We usually include usage and functionality in one RFE. That way reviewers can see how the feature is supposed to be used, and whether its worth to keep it. > > You may hear other opinions, but what I would do: > > - make an RFE that actually enriches failing Win32 API calls with GetLastError, using the non-sys variant (JLI_ReportErrorMessage) and just manually adding the error code at the call sites. > - If that turns out to be many call sites, we can think about adding a windows specific JLI_ReportErrorMessageSysWin32. > - If that's just 2-5 sites or so, leave it and just scrap JLI_ReportErrorMessageSys for windows. > > Just my 5 cent. The (rather incomplete) fix for this was indeed initially part of the original RFE, and only split into another bug afterwards when it was realized there was too much to fit into one PR for an easy review, but I thought it'd be less of a clutter to focus on this one first since the issue already exists in the tracker > make an RFE that actually enriches failing Win32 API calls with GetLastError, using the non-sys variant (JLI_ReportErrorMessage) and just manually adding the error code at the call sites. I don't quite get what you mean? ------------- PR: https://git.openjdk.org/jdk/pull/9870 From coleenp at openjdk.org Thu Aug 18 11:29:46 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Aug 2022 11:29:46 GMT Subject: RFR: 8292556: Clean up unused Hashtable instantiations In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 16:29:30 GMT, Coleen Phillimore wrote: > These instantiations in hashtable.cpp are now unused. Tested with tier1 on Oracle supported platforms. Thanks David! ------------- PR: https://git.openjdk.org/jdk/pull/9907 From coleenp at openjdk.org Thu Aug 18 11:29:46 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Aug 2022 11:29:46 GMT Subject: Integrated: 8292556: Clean up unused Hashtable instantiations In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 16:29:30 GMT, Coleen Phillimore wrote: > These instantiations in hashtable.cpp are now unused. Tested with tier1 on Oracle supported platforms. This pull request has now been integrated. Changeset: f2773f64 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/f2773f6404970481ed960ce132dac01feced2eac Stats: 22 lines in 1 file changed: 2 ins; 18 del; 2 mod 8292556: Clean up unused Hashtable instantiations Reviewed-by: hseigel, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/9907 From coleenp at openjdk.org Thu Aug 18 11:50:00 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Aug 2022 11:50:00 GMT Subject: RFR: 8292596: Make SymbolHashMap a ResourceHashtable Message-ID: Please review this straightforward change to use ResourceHashtable for SymbolHashMap, which is used by the Class File Reconstituter. The table maps Symbol* to constant pool indices for loaded classes (Symbol refcounting unnecessary as the class is not unloaded because it's in use). Tested with jvmti tests locally and tier 1-3. ------------- Commit messages: - Use ResourceHashtable for SymbolHashMap for class file reconstitutor Changes: https://git.openjdk.org/jdk/pull/9917/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9917&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292596 Stats: 132 lines in 2 files changed: 0 ins; 122 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/9917.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9917/head:pull/9917 PR: https://git.openjdk.org/jdk/pull/9917 From stuefe at openjdk.org Thu Aug 18 13:26:07 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 18 Aug 2022 13:26:07 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10] In-Reply-To: References: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com> <92O7ygNu0UfHUfRaFp3KuNQ5PQe3tf2AGmDRXwgwRAg=.641f4e87-9c75-4e2f-8c81-fb9a32372c32@github.com> <7PP7QsJ9FmXSuiWlnM8nahCiLxuQA5rX25WW85Zs504=.a9c44739-e37f-422c-b014-77974d1a69a2@github.com> Message-ID: On Thu, 18 Aug 2022 11:23:00 GMT, Julian Waters wrote: > I don't quite get what you mean? The only thing JLI_ReportErrorMessageSys has above JLI_ReportErrorMessage is that it prints the error code for you, and that is a very slim win. It turns into a loss quickly if it does that one thing wrong, e.g. by printing unrelated error codes that confuse the analyst. And if that causes us and you to burn cycles with this discussion that could be spent much better elsewhere. Therefore, what I meant to suggest is to fix whatever you originally wanted to fix with your original JBS issue https://bugs.openjdk.org/browse/JDK-8291917 by calling JLI_ReportErrorMessage directly. e.g. p = VirtualAlloc(...) or whatever win32 API you want to cover if (p == NULL) { JLI_ReportErrorMessage("Failed to allocate xxx (%u)", GetLastError()); } ------------- PR: https://git.openjdk.org/jdk/pull/9870 From kbarrett at openjdk.org Thu Aug 18 14:40:10 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 18 Aug 2022 14:40:10 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 13:11:54 GMT, Johan Sj?l?n wrote: > > How does it compare with, for example, Terekhov's algorithm? > > I'm not familiar with this algorithm, do you have a link? One place I found it. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#shared_mutex search for "shared_mutex Reference Implementation" What's proposed by this change has some similarities. This moves some state manipulation out from under the lock by using atomic operations on the state. It only has one condvar, possibly due to the limitations of our portability layer. Terekhov's algorithm is fair in the sense that neither readers nor writers get preferential treatment; it defers to the OS to decide scheduling. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From kbarrett at openjdk.org Thu Aug 18 14:46:14 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 18 Aug 2022 14:46:14 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 13:14:34 GMT, David Holmes wrote: > > For what it's worth, C++ Standard Library uses "mutex" to refer to an object that gets locked, and uses "lock" to refer to an RAII object that locks a "mutex". > > So their "lock" would be our MutexLocker? The far more dominant terminology is that a mutex is a lock. Depends on which community. I think the C++ convention makes a lot of sense, esp. given the RAII approach to locking. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From kbarrett at openjdk.org Thu Aug 18 15:00:17 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 18 Aug 2022 15:00:17 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: <_S9kQ9tERdyaDhx4uRln5RqhOwNybDYJh8-Clso4OzA=.50ed9ac7-439d-4093-b1c6-5f3c3935a6a5@github.com> References: <_S9kQ9tERdyaDhx4uRln5RqhOwNybDYJh8-Clso4OzA=.50ed9ac7-439d-4093-b1c6-5f3c3935a6a5@github.com> Message-ID: <2-9rlPUVtAGPgrzxCq8cAUsN-cKpicJtmfa1DnhKJk4=.0eb659ba-cad4-490d-be23-c877491fdd32@github.com> On Wed, 17 Aug 2022 13:02:47 GMT, David Holmes wrote: > > HotSpot Mutex has a rank, > > True, but I would put the read/write lock in the same basket as Semaphore, being completely independent of Mutex/Monitor. The onus is on the user to use them with care. A shared ranking mechanism would be tricky I think, and read locks don't fit well with ranking schemes. I would not put them in the same basket as semaphore. Semaphores are a signaling mechanism, with no concept of scope or (shared) ownership (though semaphores sometimes get conscripted into the implementation of such mechanisms). I don't see any interesting difference between an unshared locking of a shared_mutex and locking an ordinary mutex. If ranks (or anything of a similar nature) make sense for the latter, then they make sense for the former and ought to be the same mechanism. I agree that read locks with ranking could have problems. Though I wonder if "use with care" might solve most of those problems. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From hseigel at openjdk.org Thu Aug 18 15:16:08 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Thu, 18 Aug 2022 15:16:08 GMT Subject: RFR: 8292596: Make SymbolHashMap a ResourceHashtable In-Reply-To: References: Message-ID: <6nLAMGgD1pYY_yZuHTTKSrvvmhxT3W-rjK5aJ8oMZ5s=.7e349b37-31e9-4afb-87e5-4fe495b4a0e9@github.com> On Thu, 18 Aug 2022 11:41:14 GMT, Coleen Phillimore wrote: > Please review this straightforward change to use ResourceHashtable for SymbolHashMap, which is used by the Class File Reconstituter. The table maps Symbol* to constant pool indices for loaded classes (Symbol refcounting unnecessary as the class is not unloaded because it's in use). > Tested with jvmti tests locally and tier 1-3. src/hotspot/share/oops/constantPool.hpp line 921: > 919: private: > 920: // Default number of entries in the table > 921: ResourceHashtable _table; The comment at new line 920, about 'number of entries' is no longer is accurate. ------------- PR: https://git.openjdk.org/jdk/pull/9917 From coleenp at openjdk.org Thu Aug 18 15:26:12 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Aug 2022 15:26:12 GMT Subject: RFR: 8292596: Make SymbolHashMap a ResourceHashtable In-Reply-To: <6nLAMGgD1pYY_yZuHTTKSrvvmhxT3W-rjK5aJ8oMZ5s=.7e349b37-31e9-4afb-87e5-4fe495b4a0e9@github.com> References: <6nLAMGgD1pYY_yZuHTTKSrvvmhxT3W-rjK5aJ8oMZ5s=.7e349b37-31e9-4afb-87e5-4fe495b4a0e9@github.com> Message-ID: On Thu, 18 Aug 2022 15:12:25 GMT, Harold Seigel wrote: >> Please review this straightforward change to use ResourceHashtable for SymbolHashMap, which is used by the Class File Reconstituter. The table maps Symbol* to constant pool indices for loaded classes (Symbol refcounting unnecessary as the class is not unloaded because it's in use). >> Tested with jvmti tests locally and tier 1-3. > > src/hotspot/share/oops/constantPool.hpp line 921: > >> 919: private: >> 920: // Default number of entries in the table >> 921: ResourceHashtable _table; > > The comment at new line 920, about 'number of entries' is no longer is accurate. Thank you for catching that. ------------- PR: https://git.openjdk.org/jdk/pull/9917 From coleenp at openjdk.org Thu Aug 18 15:28:29 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Aug 2022 15:28:29 GMT Subject: RFR: 8292596: Make SymbolHashMap a ResourceHashtable [v2] In-Reply-To: References: Message-ID: > Please review this straightforward change to use ResourceHashtable for SymbolHashMap, which is used by the Class File Reconstituter. The table maps Symbol* to constant pool indices for loaded classes (Symbol refcounting unnecessary as the class is not unloaded because it's in use). > Tested with jvmti tests locally and tier 1-3. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9917/files - new: https://git.openjdk.org/jdk/pull/9917/files/803f8a2e..c0f966bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9917&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9917&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9917.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9917/head:pull/9917 PR: https://git.openjdk.org/jdk/pull/9917 From kbarrett at openjdk.org Thu Aug 18 15:47:13 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 18 Aug 2022 15:47:13 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: <_S9kQ9tERdyaDhx4uRln5RqhOwNybDYJh8-Clso4OzA=.50ed9ac7-439d-4093-b1c6-5f3c3935a6a5@github.com> References: <_S9kQ9tERdyaDhx4uRln5RqhOwNybDYJh8-Clso4OzA=.50ed9ac7-439d-4093-b1c6-5f3c3935a6a5@github.com> Message-ID: On Wed, 17 Aug 2022 13:00:57 GMT, David Holmes wrote: >> src/hotspot/share/runtime/mrswMutex.hpp line 63: >> >>> 61: Locker(T* lock) >>> 62: : _lock(lock) { >>> 63: if (_lock != nullptr) { >> >> When would it ever make sense for the `lock` argument to be nullptr? Instead assert in the constructor that it is not? > > It would make sense in the same circumstances the MutexLocker also takes a NULL argument. I'm going to claim that MutexLocker with a nullptr argument is a mistake, making it much harder to understand code that does that (or might do that, who knows, there's nothing in the source code to suggest one way or the other). My recollection when looking at this with Coleen a long time ago was that there are some tiny number of places that were doing that. Reasons included (1) called really early (before threads and mutexes are initialized), (2) weird (and possibly broken) things where the VMThread (thinks it) needs to ignore a lock, or (3) recursion. Making those few unusual cases look textually identical to the usual case is not very helpful, IMO. Coleen says "At one point I thought we'd squashed the null arguments to MutexLocker. We should do that." ------------- PR: https://git.openjdk.org/jdk/pull/9838 From vlivanov at openjdk.org Thu Aug 18 16:41:18 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 18 Aug 2022 16:41:18 GMT Subject: RFR: 8292564: x86: Remove redundant casts in Assembler usages In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 19:29:18 GMT, Vladimir Ivanov wrote: > Clean up Assembler API and remove redundant at use sites. > > They are not needed anymore because implicit casts between Register and integrals are forbidden now. > > Some of the casts are turned into `static_cast`s to assert that constants are small enough to fit into 32-bit immediate. > > Testing: hs-tier1 - hs-tier4 Good catch, Aleksey. I intended to use `checked_cast`, but misremembered the name. Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/9909 From vlivanov at openjdk.org Thu Aug 18 17:09:00 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 18 Aug 2022 17:09:00 GMT Subject: RFR: 8292628: x86: Improve handling of constants in trigonometric stubs Message-ID: Improve how constants are handled in trigonometric stubs on x86. In particular, extract shared constants into a separate file and encapsulate them in MacroAssembler. Also, some minor cleanups included. Testing: - [x] hs-tier1 - hs-tier4 - [x] x86_32 build ------------- Commit messages: - tabs - x86: Improve handling of constants in trigonometric stubs Changes: https://git.openjdk.org/jdk/pull/9923/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9923&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292628 Stats: 784 lines in 12 files changed: 321 ins; 360 del; 103 mod Patch: https://git.openjdk.org/jdk/pull/9923.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9923/head:pull/9923 PR: https://git.openjdk.org/jdk/pull/9923 From duke at openjdk.org Thu Aug 18 17:27:24 2022 From: duke at openjdk.org (David Phillips) Date: Thu, 18 Aug 2022 17:27:24 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 Until the JVM has an option to handle this, you can use the simple [jvmkill](https://github.com/airlift/jvmkill) JVMTI agent which does a `SIGKILL` to the current process on the `JVMTI_EVENT_RESOURCE_EXHAUSTED` event. ------------- PR: https://git.openjdk.org/jdk/pull/3586 From hseigel at openjdk.org Thu Aug 18 19:02:38 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Thu, 18 Aug 2022 19:02:38 GMT Subject: RFR: 8292596: Make SymbolHashMap a ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 15:28:29 GMT, Coleen Phillimore wrote: >> Please review this straightforward change to use ResourceHashtable for SymbolHashMap, which is used by the Class File Reconstituter. The table maps Symbol* to constant pool indices for loaded classes (Symbol refcounting unnecessary as the class is not unloaded because it's in use). >> Tested with jvmti tests locally and tier 1-3. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove comment. Changes look good! Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.org/jdk/pull/9917 From coleenp at openjdk.org Thu Aug 18 19:12:41 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Aug 2022 19:12:41 GMT Subject: RFR: 8292596: Make SymbolHashMap a ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 15:28:29 GMT, Coleen Phillimore wrote: >> Please review this straightforward change to use ResourceHashtable for SymbolHashMap, which is used by the Class File Reconstituter. The table maps Symbol* to constant pool indices for loaded classes (Symbol refcounting unnecessary as the class is not unloaded because it's in use). >> Tested with jvmti tests locally and tier 1-3. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove comment. Thanks, Harold! ------------- PR: https://git.openjdk.org/jdk/pull/9917 From coleenp at openjdk.org Thu Aug 18 19:20:08 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Aug 2022 19:20:08 GMT Subject: RFR: 8292446: Make TableRateStatistics optional in CHT [v4] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 09:22:15 GMT, Johan Sj?l?n wrote: >> Right now the footprint of disabling statistics for tables where they're not used is minimal as they're single instance and static. We're working on using CHT in more contexts, where it will be dynamically allocated, and then these changes will add up to something more substantial. >> >> Passes tier1+tier2 > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Declare functions inline src/hotspot/share/utilities/concurrentHashTable.hpp line 394: > 392: static const size_t DEFAULT_START_SIZE_LOG2 = 13; > 393: static const size_t DEFAULT_GROW_HINT = 4; // Chain length > 394: static const bool DEFAULT_ENABLE_STATISTICS = true; Ok, one last thing. I wonder if we should default to false for enabling table rate statistics? Only the StringTable and SymbolTable need it. ------------- PR: https://git.openjdk.org/jdk/pull/9899 From coleenp at openjdk.org Thu Aug 18 20:26:36 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Aug 2022 20:26:36 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 15:18:10 GMT, Johan Sj?l?n wrote: > May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? > > This PR does 3 things: > > * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot > * Adds some new utilities for writing multi-threaded tests. > * Adds some tests for MRSW Mutex using these new utilities > > The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 > > [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp I also want to echo David's bikeshedding comment. Two things - I can't speak this name so am unlikely to recommend further use of this class if someone asks, and it looks too much like Mutex which has a lot of differences, and pretty simple, so don't make that more complicated to share functionality. For some reason, I can't believe that we don't have this feature already in the vm, or at least, I was expecting this to be a simple wrapper over globalCounter.hpp. Or SingleWriterSynchronizer.hpp (whose name I can say). If it's the same as the ZGC version, maybe the ZGC version should be moved or reconciled in the utilities directory. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From coleenp at openjdk.org Thu Aug 18 20:26:38 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Aug 2022 20:26:38 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 05:07:40 GMT, David Holmes wrote: >> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? >> >> This PR does 3 things: >> >> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot >> * Adds some new utilities for writing multi-threaded tests. >> * Adds some tests for MRSW Mutex using these new utilities >> >> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 >> >> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > > src/hotspot/share/runtime/mrswMutex.hpp line 56: > >> 54: >> 55: template >> 56: class Locker : public StackObj { > > Why does this need to be a template? We only use it with PlatformMonitor. I have to echo David's question about this and the TBIVM template. I think we can be specific in both cases, so that this is understandable. If there become reasons to templateize it, we can add that. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From vlivanov at openjdk.org Thu Aug 18 21:07:43 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 18 Aug 2022 21:07:43 GMT Subject: RFR: 8292628: x86: Improve handling of constants in trigonometric stubs [v2] In-Reply-To: References: Message-ID: > Improve how constants are handled in trigonometric stubs on x86. > In particular, extract shared constants into a separate file and > encapsulate them in MacroAssembler. > > Also, some minor cleanups included. > > Testing: > - [x] hs-tier1 - hs-tier4 > - [x] x86_32 build Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: StubRoutines cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9923/files - new: https://git.openjdk.org/jdk/pull/9923/files/2141c1e4..98bfa9ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9923&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9923&range=00-01 Stats: 90 lines in 3 files changed: 0 ins; 90 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9923.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9923/head:pull/9923 PR: https://git.openjdk.org/jdk/pull/9923 From iklam at openjdk.org Thu Aug 18 21:31:12 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 18 Aug 2022 21:31:12 GMT Subject: RFR: 8292312: Work around memset() called operator new Message-ID: Please review this trivial fix. It blocks my integration for #9849: - Do not value-initialize the PtrList and PtrTable in the Synchronizer class - Use a non-default constructor for FixedResourceHashtableStorage It seems like the problem is always there, but GCC 11 would get tipped the wrong way when I moved the ObjectMonitorsHashtable() constructor from the hpp file to the cpp file in #9849. I want to make this change independent of #9849 so it can be reviewed separately, and could be backported more easily when necessary. ------------- Commit messages: - 8292312: Work around memset() called operator new Changes: https://git.openjdk.org/jdk/pull/9927/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9927&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292312 Stats: 5 lines in 3 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9927.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9927/head:pull/9927 PR: https://git.openjdk.org/jdk/pull/9927 From dcubed at openjdk.org Thu Aug 18 21:56:36 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 18 Aug 2022 21:56:36 GMT Subject: RFR: 8292312: Work around memset() called operator new In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 20:15:31 GMT, Ioi Lam wrote: > Please review this trivial fix. It blocks my integration for #9849: > - Do not value-initialize the PtrList and PtrTable in the Synchronizer class > - Use a non-default constructor for FixedResourceHashtableStorage > > It seems like the problem is always there, but GCC 11 would get tipped the wrong way when I moved the ObjectMonitorsHashtable() constructor from the hpp file to the cpp file in #9849. > > I want to make this change independent of #9849 so it can be reviewed separately, and could be backported more easily when necessary. Thumbs up. I agree that the changes are textually trivial and I see how you are working around the bug with value initialization. My brain keeps wondering how GCC 11 could be getting that wrong, but I know that you've already proven that it does. Very nice hunt! ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/9927 From vlivanov at openjdk.org Thu Aug 18 22:10:26 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 18 Aug 2022 22:10:26 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs Message-ID: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> (PR depends on #9923.) Constants which reside outside code cache are not guaranteed to be reachable in RIP-relative addressing mode from stub code, but absolute addressing mode requires a scratch register. Provide a scratch register to ensure constants are reachable irrespective of process memory layout. Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. Testing: - [x] hs-tier1 - hs-tier4 - [x] x86_32 hotspot build ------------- Depends on: https://git.openjdk.org/jdk/pull/9923 Commit messages: - 8292638: x86: Improve scratch register handling in VM stubs Changes: https://git.openjdk.org/jdk/pull/9932/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292638 Stats: 414 lines in 13 files changed: 70 ins; 97 del; 247 mod Patch: https://git.openjdk.org/jdk/pull/9932.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9932/head:pull/9932 PR: https://git.openjdk.org/jdk/pull/9932 From iklam at openjdk.org Thu Aug 18 22:30:25 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 18 Aug 2022 22:30:25 GMT Subject: RFR: 8292312: Work around memset() called operator new In-Reply-To: References: Message-ID: <-q3zg1ep7GsnIRMMqs5xPjOnvxeMZ3dCzml_3SLdmDU=.d1cc31ca-40ff-49e6-89b3-50077ce0c749@github.com> On Thu, 18 Aug 2022 21:53:05 GMT, Daniel D. Daugherty wrote: > Thumbs up. I agree that the changes are textually trivial and I see how you are working around the bug with value initialization. My brain keeps wondering how GCC 11 could be getting that wrong, but I know that you've already proven that it does. > > Very nice hunt! I think the bug has always been there (Undefined Behavior in our code) but for some reason all the C compilers emitted code that we wanted. With my change in #9849, GCC 11 suddenly emits code that's still compliant to the C++ spec but not what we wanted (memset called after operator-new). ------------- PR: https://git.openjdk.org/jdk/pull/9927 From vlivanov at openjdk.org Thu Aug 18 22:50:37 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 18 Aug 2022 22:50:37 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v2] In-Reply-To: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: > (PR depends on #9923.) > > Constants which reside outside code cache are not guaranteed to be reachable in > RIP-relative addressing mode from stub code, but absolute addressing mode requires a > scratch register. > > Provide a scratch register to ensure constants are reachable irrespective of > process memory layout. > > Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. > > Testing: > - [x] hs-tier1 - hs-tier4 > - [x] x86_32 hotspot build Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: cmp64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9932/files - new: https://git.openjdk.org/jdk/pull/9932/files/68b32113..bc87d912 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9932.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9932/head:pull/9932 PR: https://git.openjdk.org/jdk/pull/9932 From vlivanov at openjdk.org Thu Aug 18 23:01:46 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 18 Aug 2022 23:01:46 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v3] In-Reply-To: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: > (PR depends on #9923.) > > Constants which reside outside code cache are not guaranteed to be reachable in > RIP-relative addressing mode from stub code, but absolute addressing mode requires a > scratch register. > > Provide a scratch register to ensure constants are reachable irrespective of > process memory layout. > > Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. > > Testing: > - [x] hs-tier1 - hs-tier4 > - [x] x86_32 hotspot build Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: rscratch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9932/files - new: https://git.openjdk.org/jdk/pull/9932/files/bc87d912..560da5c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=01-02 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/9932.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9932/head:pull/9932 PR: https://git.openjdk.org/jdk/pull/9932 From kbarrett at openjdk.org Fri Aug 19 00:07:38 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 19 Aug 2022 00:07:38 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 20:24:26 GMT, Coleen Phillimore wrote: > For some reason, I can't believe that we don't have this feature already in the vm, or at least, I was expecting this to be a simple wrapper over globalCounter.hpp. Or SingleWriterSynchronizer.hpp (whose name I can say). If it's the same as the ZGC version, maybe the ZGC version should be moved or reconciled in the utilities directory. GlobalCounter and SingleWriterSynchronizer are RCU mechanisms. While there are some similarities in use-cases, RCU is not equivalent to a shared mutex. I think there are use-cases for shared mutex that aren't appropriate (or even feasible?) for RCU. My impression is this came up because UL has its own attempt at an RCU mechanism that is broken in both implementation and usage. (That's my 2nd-hand impression; I've not really looked at it.) One solution would be to change UL to use one of our other RCU mechanisms and fix any usage problems. Another is to introduce a shared mutex and use that. Generational ZGC has a shared mutex to deal with a specific use-case, and this PR is proposing to generalize that. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From iklam at openjdk.org Fri Aug 19 00:44:34 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Aug 2022 00:44:34 GMT Subject: RFR: 8292312: Work around memset() called operator new [v2] In-Reply-To: References: Message-ID: <5rR-cSsSKt-WUzoFmwpqV0CoAUk_FfiJNHZe7T1Ppio=.3941274a-fee1-42d8-abca-51d2539a6039@github.com> > Please review this trivial fix. It blocks my integration for #9849: > - Do not value-initialize the PtrList and PtrTable in the Synchronizer class > - Use a non-default constructor for FixedResourceHashtableStorage > > It seems like the problem is always there, but GCC 11 would get tipped the wrong way when I moved the ObjectMonitorsHashtable() constructor from the hpp file to the cpp file in #9849. > > I want to make this change independent of #9849 so it can be reviewed separately, and could be backported more easily when necessary. 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' of https://github.com/openjdk/jdk into 8292312-work-around-memset-after-operator-new - 8292312: Work around memset() called operator new ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9927/files - new: https://git.openjdk.org/jdk/pull/9927/files/70d1b352..17fa45bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9927&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9927&range=00-01 Stats: 40789 lines in 354 files changed: 18145 ins; 20252 del; 2392 mod Patch: https://git.openjdk.org/jdk/pull/9927.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9927/head:pull/9927 PR: https://git.openjdk.org/jdk/pull/9927 From dholmes at openjdk.org Fri Aug 19 01:20:33 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Aug 2022 01:20:33 GMT Subject: RFR: JDK-8292351: tty should always live [v4] In-Reply-To: References: Message-ID: <-CBcZdmJXMCg9oB6hPDibLhfMcgxw6U6QrjGsluK6_I=.192408c1-4111-4b3b-a882-f8e78115cffd@github.com> On Wed, 17 Aug 2022 09:30:48 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Change comment Hi Thomas, I think for pre-init we would look at adding an env var (which would require a CSR request) when we actually have some logging we want to add. This PR could simply do the enabling for tty to be usable at that time ie set to stdout (as the default VM output destination). Your suggestion for post-exit seems reasonable, though we may also have to consider the flag that requests VM output get logged to a file (which we probably can't do). I think it reasonable that error and warning output go to stdout/stderr in post-exit. If other more general logging needed to be added for post-exit then that would be evaluated at the time. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From dlong at openjdk.org Fri Aug 19 01:20:35 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 19 Aug 2022 01:20:35 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v6] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 09:32:54 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/code/compiledMethod.cpp line 128: >> >>> 126: if (old_status < new_status) { >>> 127: if (old_status == not_enqueued) { >>> 128: assert(extract_enqueued_deoptimization_method(_enqueued_deoptimization_link) == nullptr, "Compiled Method should not already be linked"); >> >> This doesn't work for the tail of the list, does it? That's why I suggested making the tail loop back to itself >> >> I would also like to see similar asserts added to make sure we don't recycle an nmethod that is still on the list, perhaps in nmethod::flush(). > > I think you have to describe the scenario that does not work, because I am not sure I see it. > > For ease of writing, let me call the currently embedded status `status` and the currently embedded link `next_link` > (`=>` means implies here) > > The assert checks this invariant: `status == not_enqueued => next_link == nullptr` > > After adding the first method (which will be the tail) to the list (`root == nullptr`) we will have: > * `status > not_enqueued` > * `next_link == nullptr` > > After adding any method after that ( `root != nullptr`) we will have: > * `status > not_enqueued` > * `next_link == previous_root` > > And there is also a fresh method > * `status == not_enqueued` > * `next_link == nullptr` > > If we try to enqueue an already enqueued method (calling `enqueue_deoptimization` twice) the method will have `status != not_enqueued` and will set `next_link == next_link` if `new_status > status`. (So just update the status to a stronger variant, but not change the link) > > All of these possibilities upholds the invariant. > > Maybe you are looking for some more invariant checks, like > `status > not_enqueued => InList(method)` which can be asserted by setting `next_link == this` for the tail (when `root == nullptr`) and assert that `next_link != nullptr` if `status > not_enqueued`. But it just seems like we are adding another flag for something we already check, essentially `next_link != nullptr` iff `status > not_enqueued`. > > There is currently an assert when we iterate over the list; that the number of methods we find in the list is equal to number of methods we enqueued. Yes, something like (status == not_enqueued) == !InList(method), which is strong than the current =>, and would be a sanity check on the status. > There is currently an assert when we iterate over the list; that the number of methods we find in the list is equal to number of methods we enqueued. That wouldn't necessarily catch accessing stale nmethod memory that has been released by CodeCache::free(), would it? ------------- PR: https://git.openjdk.org/jdk/pull/9655 From iklam at openjdk.org Fri Aug 19 01:20:41 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Aug 2022 01:20:41 GMT Subject: RFR: 8292318: Memory corruption in remove_dumptime_info [v3] In-Reply-To: References: Message-ID: > In [JDK-8290833](https://bugs.openjdk.org/browse/JDK-8290833) (#9759), I added a table (`SystemDictionaryShared::_saved_cpcache_entries_table`) that remembers the initial state of a `ConstantPoolCache` during CDS dumping. This table is indexed with a `ConstantPoolCache*` > > However, `ConstantPoolCache` has a complex lifecycle, especially with class redefinition. This makes it difficult to clean up the table. The crash reported in [the current bug](https://bugs.openjdk.org/browse/JDK-8292318) happened during clean up, probably because an `InstanceKlass` was still valid but its `ConstantPool` or `ConstantPoolCache` were not. > > For simplification, I am now storing the information inside the `ConstantPoolCache`. To compensate for the extra space used, I moved two 32-bit integers next to each other, so the net change in size is zero. > > instanceKlass.cpp was reverted to the state before #9759. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @calvinccheung review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9887/files - new: https://git.openjdk.org/jdk/pull/9887/files/a2872fae..d69ab667 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9887&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9887&range=01-02 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9887.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9887/head:pull/9887 PR: https://git.openjdk.org/jdk/pull/9887 From iklam at openjdk.org Fri Aug 19 01:20:43 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Aug 2022 01:20:43 GMT Subject: RFR: 8292318: Memory corruption in remove_dumptime_info [v2] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 04:55:31 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> added comments about what _initial_entries points to > > src/hotspot/share/oops/cpCache.cpp line 722: > >> 720: #if INCLUDE_CDS >> 721: MetadataFactory::free_array(data, _initial_entries); >> 722: _initial_entries = NULL; > > Should the above be inside the following condition like before? > > `if (Arguments::is_dumping_archive()) {` I added a more strict check -- since _initial_entries is set only during CDS dump time, I added an assert that if _initial_entries is non NULL, we must be dumping. ------------- PR: https://git.openjdk.org/jdk/pull/9887 From iklam at openjdk.org Fri Aug 19 02:50:30 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Aug 2022 02:50:30 GMT Subject: RFR: 8292312: Work around memset() called operator new [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 21:53:05 GMT, Daniel D. Daugherty 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' of https://github.com/openjdk/jdk into 8292312-work-around-memset-after-operator-new >> - 8292312: Work around memset() called operator new > > Thumbs up. I agree that the changes are textually trivial and I see > how you are working around the bug with value initialization. My > brain keeps wondering how GCC 11 could be getting that wrong, > but I know that you've already proven that it does. > > Very nice hunt! Thanks to @dcubed-ojdk for the review. Passed tiers1,2 and build-tier5 ------------- PR: https://git.openjdk.org/jdk/pull/9927 From iklam at openjdk.org Fri Aug 19 03:09:34 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Aug 2022 03:09:34 GMT Subject: Integrated: 8292312: Work around memset() called operator new In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 20:15:31 GMT, Ioi Lam wrote: > Please review this trivial fix. It blocks my integration for #9849: > - Do not value-initialize the PtrList and PtrTable in the Synchronizer class > - Use a non-default constructor for FixedResourceHashtableStorage > > It seems like the problem is always there, but GCC 11 would get tipped the wrong way when I moved the ObjectMonitorsHashtable() constructor from the hpp file to the cpp file in #9849. > > I want to make this change independent of #9849 so it can be reviewed separately, and could be backported more easily when necessary. This pull request has now been integrated. Changeset: 2edd5501 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/2edd5501054df5792316bcd32208e603d43951c4 Stats: 5 lines in 3 files changed: 1 ins; 0 del; 4 mod 8292312: Work around memset() called operator new Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk/pull/9927 From dholmes at openjdk.org Fri Aug 19 03:24:49 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Aug 2022 03:24:49 GMT Subject: RFR: 8292596: Make SymbolHashMap a ResourceHashtable [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 15:28:29 GMT, Coleen Phillimore wrote: >> Please review this straightforward change to use ResourceHashtable for SymbolHashMap, which is used by the Class File Reconstituter. The table maps Symbol* to constant pool indices for loaded classes (Symbol refcounting unnecessary as the class is not unloaded because it's in use). >> Tested with jvmti tests locally and tier 1-3. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove comment. These simplifications looks great. A couple of drive-by- comments, one of which is we really should decide on table versus map in the naming here. Thanks. src/hotspot/share/oops/constantPool.hpp line 923: > 921: void add_entry(const Symbol* sym, u2 value) { > 922: bool created; > 923: _table.put_if_absent(sym, value, &created); Pre-existing: Just an observation but it is very poor API naming to have `add_entry` when the semantics are actually `add_if_absent`. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9917 From iklam at openjdk.org Fri Aug 19 06:32:26 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Aug 2022 06:32:26 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp [v3] In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Message-ID: > Fix two problems with synchronizer.hpp: > > - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! > - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. > > These headers are included much less after this PR (out of ~1000 hotspot .o files) > > > linkedlist.hpp 857 -> 101 > synchronizer.hpp 848 -> 122 > resourceHash.hpp 850 -> 270 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into 8292267-clean-up-synchronizer-hpp - @dcubed-ojdk review comments - reorder class forward declarations - added back inlined functions in case their performance matters - fixed copyright - 8292267: Clean up synchronizer.hpp ------------- Changes: https://git.openjdk.org/jdk/pull/9849/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9849&range=02 Stats: 54 lines in 21 files changed: 28 ins; 21 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9849.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9849/head:pull/9849 PR: https://git.openjdk.org/jdk/pull/9849 From stefank at openjdk.org Fri Aug 19 06:48:55 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Aug 2022 06:48:55 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: <_S9kQ9tERdyaDhx4uRln5RqhOwNybDYJh8-Clso4OzA=.50ed9ac7-439d-4093-b1c6-5f3c3935a6a5@github.com> Message-ID: <_LOHkowYpfncG7PUHZXISOQRY5kW02UTF4SYRl9VM9k=.51cc43aa-5969-4469-a4c6-1f18c204d9a3@github.com> On Thu, 18 Aug 2022 15:43:42 GMT, Kim Barrett wrote: >> It would make sense in the same circumstances the MutexLocker also takes a NULL argument. > > I'm going to claim that MutexLocker with a nullptr argument is a mistake, > making it much harder to understand code that does that (or might do that, who > knows, there's nothing in the source code to suggest one way or the other). > > My recollection when looking at this with Coleen a long time ago was that > there are some tiny number of places that were doing that. Reasons included > (1) called really early (before threads and mutexes are initialized), (2) > weird (and possibly broken) things where the VMThread (thinks it) needs to > ignore a lock, or (3) recursion. Making those few unusual cases look textually > identical to the usual case is not very helpful, IMO. Coleen says "At one > point I thought we'd squashed the null arguments to MutexLocker. We should do > that." I think the pattern of passing a nullptr argument to Lockers is a pattern that we reach for quite often. The benefit is that it allows for a conditional scope, without messing up the surrounding code. Compare Locker locker(should_lock ? &_lock : nullptr); doit1(); doit2(); doit3(); vs if (should_lock) { Locker locker(should_lock ? &_lock : nullptr); doit1(); doit2(); doit3(); } else { doit1(); doit2(); doit3(); } or, having to go extra miles to pull out the code into helper functions: void MyClass::doall() { doit1(); doit2(); doit3(); } ... if (should_lock) { Locker locker(&_lock); doall(); } else { doall(); } The first version is much easier to read, IMHO. If you want to ban nullptrs in Lockers, I'd like to see an alternative that retains the crispness of the code. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From fjiang at openjdk.org Fri Aug 19 07:38:28 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Fri, 19 Aug 2022 07:38:28 GMT Subject: RFR: 8292575: riscv: Represent Registers as values Message-ID: Follow up [JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153) and [JDK-8292203](https://bugs.openjdk.org/browse/JDK-8292203), migrate away from pointer-based representation of Register values. It improves compile-time checking by forbidding implicit conversions between integrals and pointers. Testing: - hotspot/jdk tier1 on unmatched board - hotspot/jdk tier1 on qemu ------------- Commit messages: - Represent Registers as values Changes: https://git.openjdk.org/jdk/pull/9936/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9936&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292575 Stats: 509 lines in 14 files changed: 136 ins; 76 del; 297 mod Patch: https://git.openjdk.org/jdk/pull/9936.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9936/head:pull/9936 PR: https://git.openjdk.org/jdk/pull/9936 From duke at openjdk.org Fri Aug 19 08:41:31 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 19 Aug 2022 08:41:31 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: <6G4Ll1OFY139tjUFbncvcAtiNv6uOJ_0_BGyKp3MnwM=.8cf92f44-4ba8-48e2-a108-6cab7d37d320@github.com> On Thu, 18 Aug 2022 14:36:56 GMT, Kim Barrett wrote: >What's proposed by this change has some similarities. This moves some state manipulation out from under the lock by using atomic operations on the state. It only has one condvar, possibly due to the limitations of our portability layer. Terekhov's algorithm is fair in the sense that neither readers nor writers get preferential treatment; it defers to the OS to decide scheduling. Yeah, these are very similar solutions, seems like the major difference is the granularity of information provided by a condvar, locking instead of using atomics, and bit twiddling instead of just using the sign of a signed number. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From njian at openjdk.org Fri Aug 19 08:46:34 2022 From: njian at openjdk.org (Ningsheng Jian) Date: Fri, 19 Aug 2022 08:46:34 GMT Subject: RFR: 8292511: AArch64: Align CPU feature name for NEON with hwcap In-Reply-To: References: Message-ID: <29n3eTHuhsrltzNT6pwdcKE2MLbEAyPSbi8ODhcbsgg=.2d8c60fe-437d-4c34-827d-395f8b257cf4@github.com> On Thu, 18 Aug 2022 08:13:29 GMT, Pengfei Li wrote: > AArch64 hwcap uses `asimd` to represent the CPU feature of NEON. But in > vm_version_aarch64.hpp, this name is redefined as `simd`. This renaming > looks trivial but can easily lead to bugs in test cases as more and more > people start writing jtreg IR tests today. > > For example, if someone just finds CPU feature name from some documents > or `/proc/cpuinfo`, and writes below annotations in his test case, the > test case won't run on AArch64. > - `@requires vm.cpu.features ~= ".*asimd.*"` > - `@IR(applyIfCPUFeature = {"asimd", "true"}, counts = {...})` > > So in this patch we propose to align the CPU feature names. Some related > jtreg cases are also updated. There's another misalignment of the names > for CPU feature `sha2`. We don't change it as we have some discussions > in https://bugs.openjdk.org/browse/JDK-8285266. > > Tested tier1 and hotspot:compiler/vectorapi on x86 and AArch64. Looks good. ------------- Marked as reviewed by njian (Committer). PR: https://git.openjdk.org/jdk/pull/9913 From pli at openjdk.org Fri Aug 19 09:10:33 2022 From: pli at openjdk.org (Pengfei Li) Date: Fri, 19 Aug 2022 09:10:33 GMT Subject: RFR: 8292511: AArch64: Align CPU feature name for NEON with hwcap In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 08:13:29 GMT, Pengfei Li wrote: > AArch64 hwcap uses `asimd` to represent the CPU feature of NEON. But in > vm_version_aarch64.hpp, this name is redefined as `simd`. This renaming > looks trivial but can easily lead to bugs in test cases as more and more > people start writing jtreg IR tests today. > > For example, if someone just finds CPU feature name from some documents > or `/proc/cpuinfo`, and writes below annotations in his test case, the > test case won't run on AArch64. > - `@requires vm.cpu.features ~= ".*asimd.*"` > - `@IR(applyIfCPUFeature = {"asimd", "true"}, counts = {...})` > > So in this patch we propose to align the CPU feature names. Some related > jtreg cases are also updated. There's another misalignment of the names > for CPU feature `sha2`. We don't change it as we have some discussions > in https://bugs.openjdk.org/browse/JDK-8285266. > > Tested tier1 and hotspot:compiler/vectorapi on x86 and AArch64. Thanks for your review. I will integrate this. ------------- PR: https://git.openjdk.org/jdk/pull/9913 From pli at openjdk.org Fri Aug 19 09:11:56 2022 From: pli at openjdk.org (Pengfei Li) Date: Fri, 19 Aug 2022 09:11:56 GMT Subject: Integrated: 8292511: AArch64: Align CPU feature name for NEON with hwcap In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 08:13:29 GMT, Pengfei Li wrote: > AArch64 hwcap uses `asimd` to represent the CPU feature of NEON. But in > vm_version_aarch64.hpp, this name is redefined as `simd`. This renaming > looks trivial but can easily lead to bugs in test cases as more and more > people start writing jtreg IR tests today. > > For example, if someone just finds CPU feature name from some documents > or `/proc/cpuinfo`, and writes below annotations in his test case, the > test case won't run on AArch64. > - `@requires vm.cpu.features ~= ".*asimd.*"` > - `@IR(applyIfCPUFeature = {"asimd", "true"}, counts = {...})` > > So in this patch we propose to align the CPU feature names. Some related > jtreg cases are also updated. There's another misalignment of the names > for CPU feature `sha2`. We don't change it as we have some discussions > in https://bugs.openjdk.org/browse/JDK-8285266. > > Tested tier1 and hotspot:compiler/vectorapi on x86 and AArch64. This pull request has now been integrated. Changeset: f2f0cd86 Author: Pengfei Li URL: https://git.openjdk.org/jdk/commit/f2f0cd86bf4dce4633f484476077fd090549780e Stats: 17 lines in 5 files changed: 0 ins; 0 del; 17 mod 8292511: AArch64: Align CPU feature name for NEON with hwcap Reviewed-by: aph, njian ------------- PR: https://git.openjdk.org/jdk/pull/9913 From aboldtch at openjdk.org Fri Aug 19 09:38:34 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 19 Aug 2022 09:38:34 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v6] In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 01:17:14 GMT, Dean Long wrote: >> I think you have to describe the scenario that does not work, because I am not sure I see it. >> >> For ease of writing, let me call the currently embedded status `status` and the currently embedded link `next_link` >> (`=>` means implies here) >> >> The assert checks this invariant: `status == not_enqueued => next_link == nullptr` >> >> After adding the first method (which will be the tail) to the list (`root == nullptr`) we will have: >> * `status > not_enqueued` >> * `next_link == nullptr` >> >> After adding any method after that ( `root != nullptr`) we will have: >> * `status > not_enqueued` >> * `next_link == previous_root` >> >> And there is also a fresh method >> * `status == not_enqueued` >> * `next_link == nullptr` >> >> If we try to enqueue an already enqueued method (calling `enqueue_deoptimization` twice) the method will have `status != not_enqueued` and will set `next_link == next_link` if `new_status > status`. (So just update the status to a stronger variant, but not change the link) >> >> All of these possibilities upholds the invariant. >> >> Maybe you are looking for some more invariant checks, like >> `status > not_enqueued => InList(method)` which can be asserted by setting `next_link == this` for the tail (when `root == nullptr`) and assert that `next_link != nullptr` if `status > not_enqueued`. But it just seems like we are adding another flag for something we already check, essentially `next_link != nullptr` iff `status > not_enqueued`. >> >> There is currently an assert when we iterate over the list; that the number of methods we find in the list is equal to number of methods we enqueued. > > Yes, something like (status == not_enqueued) == !InList(method), which is strong than the current =>, and would be a sanity check on the status. > >> There is currently an assert when we iterate over the list; that the number of methods we find in the list is equal to number of methods we enqueued. > > That wouldn't necessarily catch accessing stale nmethod memory that has been released by CodeCache::free(), would it? Yeah the point of that assert was simply to check the sanity of the iteration implementation. The validity of the actual pointer is suppose to be guaranteed by the deoptimization context. I think adding asserts that we are inside deoptimization context would be good. You have a point about nmethods becoming stale. In the world with the sweeper my understanding is that if we add a `is_alive` method to the list it will not be flushed and freed until after the next safepoint, which the context ensures does not happen until the list is processed. And in the world after the sweeper the nmethods are just stable if no safepoint occurs. Because they would be unlinked in an earlier phase so we do not see them while iterating the code cache, and when walking dependency contexts it only returns not unloading nmethods. Maybe this deoptimization interface should just explicitly not add not alive, or unloading methods. Or just assert it and leave it up to the users of the interface. I think that invariant is upheld today. But I will investigate. Maybe some of the whitebox APIs. Erik will be back next week so I will discuss this with him. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From aboldtch at openjdk.org Fri Aug 19 10:25:49 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 19 Aug 2022 10:25:49 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v7] In-Reply-To: References: Message-ID: <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com> > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Add context active assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9655/files - new: https://git.openjdk.org/jdk/pull/9655/files/4b95396c..ab144688 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=05-06 Stats: 10 lines in 3 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From duke at openjdk.org Fri Aug 19 10:28:46 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 19 Aug 2022 10:28:46 GMT Subject: RFR: 8292446: Make TableRateStatistics optional in CHT [v5] In-Reply-To: References: Message-ID: > Right now the footprint of disabling statistics for tables where they're not used is minimal as they're single instance and static. We're working on using CHT in more contexts, where it will be dynamically allocated, and then these changes will add up to something more substantial. > > Passes tier1+tier2 Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Make statistics disabled by defalt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9899/files - new: https://git.openjdk.org/jdk/pull/9899/files/8353bbc3..66aecbbb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9899&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9899&range=03-04 Stats: 8 lines in 6 files changed: 0 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9899.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9899/head:pull/9899 PR: https://git.openjdk.org/jdk/pull/9899 From duke at openjdk.org Fri Aug 19 10:50:38 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 19 Aug 2022 10:50:38 GMT Subject: RFR: 8292446: Make TableRateStatistics optional in CHT [v4] In-Reply-To: References: Message-ID: <0llP4uRleM3gncIuWx6-RWinxu2t5xEnKeQoMWaA_hs=.0c5041f3-87ab-441b-bbe3-37ad738dbafe@github.com> On Thu, 18 Aug 2022 19:16:18 GMT, Coleen Phillimore wrote: >> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: >> >> Declare functions inline > > src/hotspot/share/utilities/concurrentHashTable.hpp line 394: > >> 392: static const size_t DEFAULT_START_SIZE_LOG2 = 13; >> 393: static const size_t DEFAULT_GROW_HINT = 4; // Chain length >> 394: static const bool DEFAULT_ENABLE_STATISTICS = true; > > Ok, one last thing. I wonder if we should default to false for enabling table rate statistics? Only the StringTable and SymbolTable need it. Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/9899 From shade at openjdk.org Fri Aug 19 12:41:34 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 19 Aug 2022 12:41:34 GMT Subject: RFR: 8292628: x86: Improve handling of constants in trigonometric stubs [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 21:07:43 GMT, Vladimir Ivanov wrote: >> Improve how constants are handled in trigonometric stubs on x86. >> In particular, extract shared constants into a separate file and >> encapsulate them in MacroAssembler. >> >> Also, some minor cleanups included. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 >> - [x] x86_32 build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > StubRoutines cleanup Looks okay with some nits. src/hotspot/cpu/x86/macroAssembler_x86_constants.cpp line 251: > 249: > 250: ATTRIBUTE_ALIGNED(16) juint _PI4X3[] = { > 251: 0x54443000UL, 0xbfe921fbUL, 0x3b39a000UL, 0x3d373dcbUL, 0xe0e68948UL, 0xba845c06UL While at it, maybe we should stick to one style for these tables. The large table above has five columns, so maybe wrap this and following table like that too? src/hotspot/cpu/x86/macroAssembler_x86_exp.cpp line 206: > 204: movdqu(xmm6, ExternalAddress(SHIFTER)); // 0x00000000UL, 0x43380000UL, 0x00000000UL, 0x43380000UL > 205: movdqu(xmm2, ExternalAddress(16 + cv)); // 0xfefa0000UL, 0x3f862e42UL, 0xfefa0000UL, 0x3f862e42UL > 206: movdqu(xmm3, ExternalAddress(32 + cv)); // 0xbc9e3b3aUL, 0x3d1cf79aUL, 0xbc9e3b3aUL, 0x3d1cf79aUL If you are flipping `+` operands near the changes, maybe flip these too? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9923 From coleenp at openjdk.org Fri Aug 19 12:50:32 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Aug 2022 12:50:32 GMT Subject: RFR: JDK-8292351: tty should always live [v4] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 09:30:48 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Change comment I think this is fine as a last chance handler. If we do need pre-init and post-exit logging, ie things come out to this output, we can re-evaluate and move the defaultStream destructor later or have some pre-init logging functionality. This seems good for reliably getting bug reports but should rarely be needed. If you find otherwise, please file an RFE. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/9874 From shade at openjdk.org Fri Aug 19 13:36:35 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 19 Aug 2022 13:36:35 GMT Subject: RFR: 8292564: x86: Remove redundant casts in Assembler usages [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 16:41:16 GMT, Vladimir Ivanov wrote: >> Clean up Assembler API and remove redundant at use sites. >> >> They are not needed anymore because implicit casts between Register and integrals are forbidden now. >> >> Some of the casts are turned into `static_cast`s to assert that constants are small enough to fit into 32-bit immediate. >> >> Testing: hs-tier1 - hs-tier4 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > checked_cast Looks fine. I also tested with Alpine builds, that are known to get funky with `intptr_t` conversions. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9909 From coleenp at openjdk.org Fri Aug 19 13:53:25 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Aug 2022 13:53:25 GMT Subject: RFR: 8292596: Make SymbolHashMap a ResourceHashtable [v3] In-Reply-To: References: Message-ID: > Please review this straightforward change to use ResourceHashtable for SymbolHashMap, which is used by the Class File Reconstituter. The table maps Symbol* to constant pool indices for loaded classes (Symbol refcounting unnecessary as the class is not unloaded because it's in use). > Tested with jvmti tests locally and tier 1-3. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9917/files - new: https://git.openjdk.org/jdk/pull/9917/files/c0f966bb..da82d26c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9917&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9917&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9917.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9917/head:pull/9917 PR: https://git.openjdk.org/jdk/pull/9917 From coleenp at openjdk.org Fri Aug 19 14:16:34 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Aug 2022 14:16:34 GMT Subject: RFR: 8292446: Make TableRateStatistics optional in CHT [v5] In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 10:28:46 GMT, Johan Sj?l?n wrote: >> Right now the footprint of disabling statistics for tables where they're not used is minimal as they're single instance and static. We're working on using CHT in more contexts, where it will be dynamically allocated, and then these changes will add up to something more substantial. >> >> Passes tier1+tier2 > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Make statistics disabled by defalt This looks really good! Thank you for fixing this! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/9899 From roland at openjdk.org Fri Aug 19 14:19:58 2022 From: roland at openjdk.org (Roland Westrelin) Date: Fri, 19 Aug 2022 14:19:58 GMT Subject: RFR: 8292671: Hotspot Style Guide should allow covariant returnts Message-ID: The style guide explicitly lists covariant returns as a disallowed feature of c++. I propose we allow that feature. This came up on the c2 side where, with JDK-8275201, I introduced some uses of covariant returns at a number of locations in the c2 code because I felt the code was cleaner that way. I wasn't aware it was mentioned on the style guide. This was noticed by another openjdk contributor and I prepared a change to revert the use of covariant returns I had introduced: https://github.com/openjdk/jdk/pull/9237 But it feels that change actually makes the code less clear and comments on the PR indicates some other contributors feel the same way. It's unclear to me why covariant returns are disallowed in the first place and the (few) contributors I asked don't seem to know either. So I propose simply allowing covariant returns. ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/9941/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9941&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292671 Stats: 7 lines in 2 files changed: 3 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9941.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9941/head:pull/9941 PR: https://git.openjdk.org/jdk/pull/9941 From coleenp at openjdk.org Fri Aug 19 14:53:34 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Aug 2022 14:53:34 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: <_LOHkowYpfncG7PUHZXISOQRY5kW02UTF4SYRl9VM9k=.51cc43aa-5969-4469-a4c6-1f18c204d9a3@github.com> References: <_S9kQ9tERdyaDhx4uRln5RqhOwNybDYJh8-Clso4OzA=.50ed9ac7-439d-4093-b1c6-5f3c3935a6a5@github.com> <_LOHkowYpfncG7PUHZXISOQRY5kW02UTF4SYRl9VM9k=.51cc43aa-5969-4469-a4c6-1f18c204d9a3@github.com> Message-ID: On Fri, 19 Aug 2022 06:46:17 GMT, Stefan Karlsson wrote: >> I'm going to claim that MutexLocker with a nullptr argument is a mistake, >> making it much harder to understand code that does that (or might do that, who >> knows, there's nothing in the source code to suggest one way or the other). >> >> My recollection when looking at this with Coleen a long time ago was that >> there are some tiny number of places that were doing that. Reasons included >> (1) called really early (before threads and mutexes are initialized), (2) >> weird (and possibly broken) things where the VMThread (thinks it) needs to >> ignore a lock, or (3) recursion. Making those few unusual cases look textually >> identical to the usual case is not very helpful, IMO. Coleen says "At one >> point I thought we'd squashed the null arguments to MutexLocker. We should do >> that." > > I think the pattern of passing a nullptr argument to Lockers is a pattern that we reach for quite often. The benefit is that it allows for a conditional scope, without messing up the surrounding code. > > Compare > > Locker locker(should_lock ? &_lock : nullptr); > doit1(); > doit2(); > doit3(); > > vs > > if (should_lock) { > Locker locker(&_lock); > doit1(); > doit2(); > doit3(); > } else { > doit1(); > doit2(); > doit3(); > } > > or, having to go extra miles to pull out the code into helper functions: > > void MyClass::doall() { > doit1(); > doit2(); > doit3(); > } > ... > if (should_lock) { > Locker locker(&_lock); > doall(); > } else { > doall(); > } > > > The first version is much easier to read, IMHO. If you want to ban nullptrs in Lockers, I'd like to see an alternative that retains the crispness of the code. You can have a blah_locked() version in these cases. Having code called in multiple situations (some paths locked and some not) might be not great. Some higher level of code should have done the locking or not. That said, the sweeper has multiple of these with the Compile_lock so this can't be attempted to be squashed until the sweeper is gone. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From ihse at openjdk.org Fri Aug 19 14:56:41 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 19 Aug 2022 14:56:41 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v6] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 18:23:15 GMT, Ioi Lam wrote: >> Enable CDS for zero builds. `java --version` is about 2x faster now. >> >> >> $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version >> 0.034645 +- 0.000044 seconds time elapsed ( +- 0.13% ) >> $ perf stat -r 40 ./images/jdk/bin/java -version >> 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% ) >> >> I also fixed a bug in Images.gmk that always wrote the default archive to $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to have a default CDS archive. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > added !UseSharedSpaces back to _fast_invokevfinal check Build changes look good. Always good to get rid of duplicated code; thank you! ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/jdk/pull/9869 From rehn at openjdk.org Fri Aug 19 15:15:38 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 19 Aug 2022 15:15:38 GMT Subject: RFR: 8292446: Make TableRateStatistics optional in CHT [v5] In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 10:28:46 GMT, Johan Sj?l?n wrote: >> Right now the footprint of disabling statistics for tables where they're not used is minimal as they're single instance and static. We're working on using CHT in more contexts, where it will be dynamically allocated, and then these changes will add up to something more substantial. >> >> Passes tier1+tier2 > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Make statistics disabled by defalt Thanks for fixing! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9899 From duke at openjdk.org Fri Aug 19 15:34:45 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 19 Aug 2022 15:34:45 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v2] In-Reply-To: References: Message-ID: <03PIk7Zf62XvKZjoRob4OfixPKpshirPOrxzzOOsrgU=.7be8cb20-7aa2-4765-a7e0-6fe527d143ba@github.com> > May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? > > This PR does 3 things: > > * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot > * Adds some new utilities for writing multi-threaded tests. > * Adds some tests for MRSW Mutex using these new utilities > > The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 > > [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9838/files - new: https://git.openjdk.org/jdk/pull/9838/files/30883e04..e842c508 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9838&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9838&range=00-01 Stats: 700 lines in 6 files changed: 352 ins; 348 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9838.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9838/head:pull/9838 PR: https://git.openjdk.org/jdk/pull/9838 From stefank at openjdk.org Fri Aug 19 15:37:50 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Aug 2022 15:37:50 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v2] In-Reply-To: References: <_S9kQ9tERdyaDhx4uRln5RqhOwNybDYJh8-Clso4OzA=.50ed9ac7-439d-4093-b1c6-5f3c3935a6a5@github.com> <_LOHkowYpfncG7PUHZXISOQRY5kW02UTF4SYRl9VM9k=.51cc43aa-5969-4469-a4c6-1f18c204d9a3@github.com> Message-ID: On Fri, 19 Aug 2022 14:50:11 GMT, Coleen Phillimore wrote: >> I think the pattern of passing a nullptr argument to Lockers is a pattern that we reach for quite often. The benefit is that it allows for a conditional scope, without messing up the surrounding code. >> >> Compare >> >> Locker locker(should_lock ? &_lock : nullptr); >> doit1(); >> doit2(); >> doit3(); >> >> vs >> >> if (should_lock) { >> Locker locker(&_lock); >> doit1(); >> doit2(); >> doit3(); >> } else { >> doit1(); >> doit2(); >> doit3(); >> } >> >> or, having to go extra miles to pull out the code into helper functions: >> >> void MyClass::doall() { >> doit1(); >> doit2(); >> doit3(); >> } >> ... >> if (should_lock) { >> Locker locker(&_lock); >> doall(); >> } else { >> doall(); >> } >> >> >> The first version is much easier to read, IMHO. If you want to ban nullptrs in Lockers, I'd like to see an alternative that retains the crispness of the code. > > You can have a blah_locked() version in these cases. Having code called in multiple situations (some paths locked and some not) might be not great. Some higher level of code should have done the locking or not. > That said, the sweeper has multiple of these with the Compile_lock so this can't be attempted to be squashed until the sweeper is gone. I've gotten more push-back on things called blah_locked(). The motivation was that it's not clear if it is the caller or callee who should take the lock, so that name convention isn't really helping the reader. I'm a but sympathetic to that point-of-view. I still don't think this is something we should be squashing. Maybe it would help sway me if someone tried to convert ZActivatedArray and show what the code would look like if we couldn't use this pattern: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zArray.inline.hpp Alternatively, we could have two versions of lockers to appease both sides? One that never accepts nullptr, which would be the locker that most should be using, and one for those cases where we do need to run with and without the lock held. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From duke at openjdk.org Fri Aug 19 15:46:36 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 19 Aug 2022 15:46:36 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v2] In-Reply-To: <03PIk7Zf62XvKZjoRob4OfixPKpshirPOrxzzOOsrgU=.7be8cb20-7aa2-4765-a7e0-6fe527d143ba@github.com> References: <03PIk7Zf62XvKZjoRob4OfixPKpshirPOrxzzOOsrgU=.7be8cb20-7aa2-4765-a7e0-6fe527d143ba@github.com> Message-ID: On Fri, 19 Aug 2022 15:34:45 GMT, Johan Sj?l?n wrote: >> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? >> >> This PR does 3 things: >> >> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot >> * Adds some new utilities for writing multi-threaded tests. >> * Adds some tests for MRSW Mutex using these new utilities >> >> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 >> >> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Review comments I just pushed my first clean up of this code based on your comments. Here's a short summary: 1. Rename to ReadWriteLock 2. Move to utilities 3. Remove template, use a conditional branch + lambda for ThreadBlockInVM (painful way of doing it, stefank has a good idea with the nullptr strategy) 4. Clarify some comments 5. Remove nullptr case from Locker, as it's not used in this code anyway 6. Use int32_t instead of int64_t for counter Some of your comments are still not handled. Off the top of my head, I'm still not documenting everything that dholmes is interested in. @robehn has mentioned to me that there are issues when a safepointed thread holds a lock that the VM thread wants to hold, so that needs to be handled (he has also pointed out how to handle this). Kim mentioned that UL might want to use GlobalCounter instead. This is viable, but contention on the global counter may lead to performance degradation for other users, AFAIK. Finally, I will be simplifying this PR by pulling out the additions to threadHelper.inline.hpp into its own PR. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From coleenp at openjdk.org Fri Aug 19 15:55:53 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Aug 2022 15:55:53 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v2] In-Reply-To: References: <_S9kQ9tERdyaDhx4uRln5RqhOwNybDYJh8-Clso4OzA=.50ed9ac7-439d-4093-b1c6-5f3c3935a6a5@github.com> <_LOHkowYpfncG7PUHZXISOQRY5kW02UTF4SYRl9VM9k=.51cc43aa-5969-4469-a4c6-1f18c204d9a3@github.com> Message-ID: On Fri, 19 Aug 2022 15:35:34 GMT, Stefan Karlsson wrote: >> You can have a blah_locked() version in these cases. Having code called in multiple situations (some paths locked and some not) might be not great. Some higher level of code should have done the locking or not. >> That said, the sweeper has multiple of these with the Compile_lock so this can't be attempted to be squashed until the sweeper is gone. > > I've gotten more push-back on things called blah_locked(). The motivation was that it's not clear if it is the caller or callee who should take the lock, so that name convention isn't really helping the reader. I'm a but sympathetic to that point-of-view. > > I still don't think this is something we should be squashing. Maybe it would help sway me if someone tried to convert ZActivatedArray and show what the code would look like if we couldn't use this pattern: > https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zArray.inline.hpp > > Alternatively, we could have two versions of lockers to appease both sides? One that never accepts nullptr, which would be the locker that most should be using, and one for those cases where we do need to run with and without the lock held. I don't now if your zlock is even a standard runtime/mutex, but let's definitely not have another version of lockers. I've never pushed back on blah_locked(). I need to see more evidence of why we need null mutex in the code (after the sweeper is removed), before I suggest a policy change. I have a patch that removes the NULL ObjectLocker argument. I thought ObjectLocker was the only thing that took null until yesterday. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From coleenp at openjdk.org Fri Aug 19 16:00:36 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Aug 2022 16:00:36 GMT Subject: RFR: 8292596: Make SymbolHashMap a ResourceHashtable [v4] In-Reply-To: References: Message-ID: > Please review this straightforward change to use ResourceHashtable for SymbolHashMap, which is used by the Class File Reconstituter. The table maps Symbol* to constant pool indices for loaded classes (Symbol refcounting unnecessary as the class is not unloaded because it's in use). > Tested with jvmti tests locally and tier 1-3. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Hide SymbolHash inside of ConstantPool so people don't get the wrong idea about it. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9917/files - new: https://git.openjdk.org/jdk/pull/9917/files/da82d26c..7f3d9c24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9917&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9917&range=02-03 Stats: 44 lines in 4 files changed: 16 ins; 17 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/9917.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9917/head:pull/9917 PR: https://git.openjdk.org/jdk/pull/9917 From duke at openjdk.org Fri Aug 19 16:42:28 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 19 Aug 2022 16:42:28 GMT Subject: Integrated: 8292446: Make TableRateStatistics optional in CHT In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 09:42:00 GMT, Johan Sj?l?n wrote: > Right now the footprint of disabling statistics for tables where they're not used is minimal as they're single instance and static. We're working on using CHT in more contexts, where it will be dynamically allocated, and then these changes will add up to something more substantial. > > Passes tier1+tier2 This pull request has now been integrated. Changeset: 1f3578b7 Author: Johan Sj?l?n Committer: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/1f3578b79c6355b976d64756da7e4a8af32c2987 Stats: 56 lines in 8 files changed: 28 ins; 11 del; 17 mod 8292446: Make TableRateStatistics optional in CHT Reviewed-by: coleenp, rehn ------------- PR: https://git.openjdk.org/jdk/pull/9899 From jrose at openjdk.org Fri Aug 19 16:46:49 2022 From: jrose at openjdk.org (John R Rose) Date: Fri, 19 Aug 2022 16:46:49 GMT Subject: RFR: 8292671: Hotspot Style Guide should allow covariant returns In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 14:12:05 GMT, Roland Westrelin wrote: > The style guide explicitly lists covariant returns as a disallowed > feature of c++. I propose we allow that feature. > > This came up on the c2 side where, with JDK-8275201, I introduced some > uses of covariant returns at a number of locations in the c2 code > because I felt the code was cleaner that way. I wasn't aware it was > mentioned on the style guide. This was noticed by another openjdk > contributor and I prepared a change to revert the use of covariant > returns I had introduced: > > https://github.com/openjdk/jdk/pull/9237 > > But it feels that change actually makes the code less clear and > comments on the PR indicates some other contributors feel the same > way. > > It's unclear to me why covariant returns are disallowed in the first > place and the (few) contributors I asked don't seem to know either. So > I propose simply allowing covariant returns. Yes, this is fine. That restriction was written long ago, before Java itself allowed covariant returns. IIRC there are (and were) no other reasons, other than to avoid a slightly tricky language feature not familiar (at the time) to Java programmers. Covariance is type-safe (as applied to returns of overrides) and introduces no hidden runtime costs. ------------- Marked as reviewed by jrose (Reviewer). PR: https://git.openjdk.org/jdk/pull/9941 From iklam at openjdk.org Fri Aug 19 17:25:41 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Aug 2022 17:25:41 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp [v3] In-Reply-To: <39nneFOUe-wR-G9IjpEaDdLOI8ihO04p1Vv6deQDInc=.e00c9cf9-9bd5-4691-bb0a-2e6a1421c8a0@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> <39nneFOUe-wR-G9IjpEaDdLOI8ihO04p1Vv6deQDInc=.e00c9cf9-9bd5-4691-bb0a-2e6a1421c8a0@github.com> Message-ID: On Fri, 12 Aug 2022 13:20:32 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Merge branch 'master' into 8292267-clean-up-synchronizer-hpp >> - @dcubed-ojdk review comments - reorder class forward declarations >> - added back inlined functions in case their performance matters >> - fixed copyright >> - 8292267: Clean up synchronizer.hpp > > Very nice. Thanks @coleenp @dholmes-ora @dcubed-ojdk for the review. Tiers 1,2 and build-tier5 passed on top of #9927 ------------- PR: https://git.openjdk.org/jdk/pull/9849 From iklam at openjdk.org Fri Aug 19 17:29:38 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Aug 2022 17:29:38 GMT Subject: Integrated: 8292267: Clean up synchronizer.hpp In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Message-ID: On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam wrote: > Fix two problems with synchronizer.hpp: > > - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! > - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. > > These headers are included much less after this PR (out of ~1000 hotspot .o files) > > > linkedlist.hpp 857 -> 101 > synchronizer.hpp 848 -> 122 > resourceHash.hpp 850 -> 270 This pull request has now been integrated. Changeset: 7244dd6f Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/7244dd6fab0c516ed76af594593b8378512620c8 Stats: 54 lines in 21 files changed: 28 ins; 21 del; 5 mod 8292267: Clean up synchronizer.hpp Reviewed-by: coleenp, dcubed, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/9849 From vlivanov at openjdk.org Fri Aug 19 17:52:11 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 19 Aug 2022 17:52:11 GMT Subject: RFR: 8292564: x86: Remove redundant casts in Assembler usages [v2] In-Reply-To: References: Message-ID: <60U0RpF7Fy0Zdkb0Yq2nV6TnAtQ3_wEhFYbhCLQfvsA=.f2882dbc-3e77-4412-a5a2-463440fd218e@github.com> On Thu, 18 Aug 2022 16:41:16 GMT, Vladimir Ivanov wrote: >> Clean up Assembler API and remove redundant at use sites. >> >> They are not needed anymore because implicit casts between Register and integrals are forbidden now. >> >> Some of the casts are turned into `static_cast`s to assert that constants are small enough to fit into 32-bit immediate. >> >> Testing: hs-tier1 - hs-tier4 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > checked_cast Thanks for the reviews, Igor, Vladimir, and Aleksey. ------------- PR: https://git.openjdk.org/jdk/pull/9909 From vlivanov at openjdk.org Fri Aug 19 17:53:08 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 19 Aug 2022 17:53:08 GMT Subject: RFR: 8292628: x86: Improve handling of constants in trigonometric stubs [v3] In-Reply-To: References: Message-ID: <9hAvoERJGWeVIjHqbtDBieCerZxSb1j8MtxmrJ8FDzw=.3d38a8c4-e088-4d5c-a449-6dc752e36e8b@github.com> > Improve how constants are handled in trigonometric stubs on x86. > In particular, extract shared constants into a separate file and > encapsulate them in MacroAssembler. > > Also, some minor cleanups included. > > Testing: > - [x] hs-tier1 - hs-tier4 > - [x] x86_32 build Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: cleanups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9923/files - new: https://git.openjdk.org/jdk/pull/9923/files/98bfa9ec..e867e115 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9923&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9923&range=01-02 Stats: 8 lines in 2 files changed: 4 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9923.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9923/head:pull/9923 PR: https://git.openjdk.org/jdk/pull/9923 From vlivanov at openjdk.org Fri Aug 19 18:03:31 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 19 Aug 2022 18:03:31 GMT Subject: RFR: 8292628: x86: Improve handling of constants in trigonometric stubs [v2] In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 12:30:34 GMT, Aleksey Shipilev wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> StubRoutines cleanup > > src/hotspot/cpu/x86/macroAssembler_x86_constants.cpp line 251: > >> 249: >> 250: ATTRIBUTE_ALIGNED(16) juint _PI4X3[] = { >> 251: 0x54443000UL, 0xbfe921fbUL, 0x3b39a000UL, 0x3d373dcbUL, 0xe0e68948UL, 0xba845c06UL > > While at it, maybe we should stick to one style for these tables. The large table above has five columns, so maybe wrap this and following table like that too? Sounds good. Fixed. > src/hotspot/cpu/x86/macroAssembler_x86_exp.cpp line 206: > >> 204: movdqu(xmm6, ExternalAddress(SHIFTER)); // 0x00000000UL, 0x43380000UL, 0x00000000UL, 0x43380000UL >> 205: movdqu(xmm2, ExternalAddress(16 + cv)); // 0xfefa0000UL, 0x3f862e42UL, 0xfefa0000UL, 0x3f862e42UL >> 206: movdqu(xmm3, ExternalAddress(32 + cv)); // 0xbc9e3b3aUL, 0x3d1cf79aUL, 0xbc9e3b3aUL, 0x3d1cf79aUL > > If you are flipping `+` operands near the changes, maybe flip these too? Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/9923 From iklam at openjdk.org Fri Aug 19 18:47:50 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Aug 2022 18:47:50 GMT Subject: RFR: 8290981: Enable CDS for zero builds [v2] In-Reply-To: References: <9V2m7GcGbNzcUyJ-Wha5LdW1-EeHeGiEYWR-l0nwCG4=.aabacaa1-0d08-4095-9b5c-37e35cb12aec@github.com> <5sG7YDdsl8g7JlNW0l40ez8OfiFudQDDSRuKZgodXhU=.cb42b06d-60a8-48c9-badd-b7d7e6a35e84@github.com> Message-ID: On Tue, 16 Aug 2022 06:36:26 GMT, Aleksey Shipilev wrote: >>> Do you know how much testing is done by the community with zero? We don't test it that much in our pipeline. >> >> You could ask the Debian people (Adrian Glaubitz), IIRC they have test farms with broad platform support and use a lot of zero. > >> > Do you know how much testing is done by the community with zero? We don't test it that much in our pipeline. >> >> You could ask the Debian people (Adrian Glaubitz), IIRC they have test farms with broad platform support and use a lot of zero. > > Yes, Debian seems to rely on Zero for many arches that do not have Server ports. They discover the bugs sometimes, but I think it got much better once we started doing x86_64 Zero bootcycle tests for incoming Zero patches -- it shakes out a lot of simple bugs. @shipilev Thanks for the code contribution and testing! @tstuefe @magicus @erikj79 Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/9869 From vlivanov at openjdk.org Fri Aug 19 19:18:58 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 19 Aug 2022 19:18:58 GMT Subject: Integrated: 8292564: x86: Remove redundant casts in Assembler usages In-Reply-To: References: Message-ID: <63r1gKpfYNnpW7foBd1Wk9UNxwuuexu79vCkipqmY_o=.fdf9536a-53ec-48bc-a926-8e72ebdde681@github.com> On Wed, 17 Aug 2022 19:29:18 GMT, Vladimir Ivanov wrote: > Clean up Assembler API and remove redundant at use sites. > > They are not needed anymore because implicit casts between Register and integrals are forbidden now. > > Some of the casts are turned into `static_cast`s to assert that constants are small enough to fit into 32-bit immediate. > > Testing: hs-tier1 - hs-tier4 This pull request has now been integrated. Changeset: 6a8a5313 Author: Vladimir Ivanov URL: https://git.openjdk.org/jdk/commit/6a8a531359295849113aa14fd6cba21c886decf3 Stats: 167 lines in 23 files changed: 0 ins; 35 del; 132 mod 8292564: x86: Remove redundant casts in Assembler usages Reviewed-by: iveresov, kvn, shade ------------- PR: https://git.openjdk.org/jdk/pull/9909 From iklam at openjdk.org Fri Aug 19 19:21:49 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Aug 2022 19:21:49 GMT Subject: Integrated: 8290981: Enable CDS for zero builds In-Reply-To: References: Message-ID: On Sun, 14 Aug 2022 05:21:13 GMT, Ioi Lam wrote: > Enable CDS for zero builds. `java --version` is about 2x faster now. > > > $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version > 0.034645 +- 0.000044 seconds time elapsed ( +- 0.13% ) > $ perf stat -r 40 ./images/jdk/bin/java -version > 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% ) > > I also fixed a bug in Images.gmk that always wrote the default archive to $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to have a default CDS archive. This pull request has now been integrated. Changeset: 57aac2ab Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/57aac2ab6569c18a56e9a36f174bb0bf09955f83 Stats: 134 lines in 5 files changed: 63 ins; 28 del; 43 mod 8290981: Enable CDS for zero builds Co-authored-by: Aleksey Shipilev Reviewed-by: erikj, shade, ihse ------------- PR: https://git.openjdk.org/jdk/pull/9869 From kvn at openjdk.org Fri Aug 19 20:04:53 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 19 Aug 2022 20:04:53 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v3] In-Reply-To: References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: On Thu, 18 Aug 2022 23:01:46 GMT, Vladimir Ivanov wrote: >> (PR depends on #9923.) >> >> Constants which reside outside code cache are not guaranteed to be reachable in >> RIP-relative addressing mode from stub code, but absolute addressing mode requires a >> scratch register. >> >> Provide a scratch register to ensure constants are reachable irrespective of >> process memory layout. >> >> Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 >> - [x] x86_32 hotspot build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > rscratch Looks good. I would suggest to run full tier1-4 mach5 testing (instead of only hs-tier*) which will run java/lang/math tests too. And tier4 runs with -Xcomp. ------------- PR: https://git.openjdk.org/jdk/pull/9932 From dholmes at openjdk.org Fri Aug 19 21:08:48 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Aug 2022 21:08:48 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v2] In-Reply-To: References: <_S9kQ9tERdyaDhx4uRln5RqhOwNybDYJh8-Clso4OzA=.50ed9ac7-439d-4093-b1c6-5f3c3935a6a5@github.com> <_LOHkowYpfncG7PUHZXISOQRY5kW02UTF4SYRl9VM9k=.51cc43aa-5969-4469-a4c6-1f18c204d9a3@github.com> Message-ID: On Fri, 19 Aug 2022 15:52:57 GMT, Coleen Phillimore wrote: >> I've gotten more push-back on things called blah_locked(). The motivation was that it's not clear if it is the caller or callee who should take the lock, so that name convention isn't really helping the reader. I'm a but sympathetic to that point-of-view. >> >> I still don't think this is something we should be squashing. Maybe it would help sway me if someone tried to convert ZActivatedArray and show what the code would look like if we couldn't use this pattern: >> https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zArray.inline.hpp >> >> Alternatively, we could have two versions of lockers to appease both sides? One that never accepts nullptr, which would be the locker that most should be using, and one for those cases where we do need to run with and without the lock held. > > I don't now if your zlock is even a standard runtime/mutex, but let's definitely not have another version of lockers. I've never pushed back on blah_locked(). I need to see more evidence of why we need null mutex in the code (after the sweeper is removed), before I suggest a policy change. > I have a patch that removes the NULL ObjectLocker argument. I thought ObjectLocker was the only thing that took null until yesterday. > Alternatively, we could have two versions of lockers to appease both sides? "They who cannot remember the past are condemned to repeat it." :) We used to have `MutexLockerEx` that allowed the NULL whereas `MutexLocker` did not. I have no issues with the NULL case as it is cleaner that defining locked and unlocked code paths. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From ccheung at openjdk.org Fri Aug 19 22:20:37 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 19 Aug 2022 22:20:37 GMT Subject: RFR: 8292318: Memory corruption in remove_dumptime_info [v3] In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 01:20:41 GMT, Ioi Lam wrote: >> In [JDK-8290833](https://bugs.openjdk.org/browse/JDK-8290833) (#9759), I added a table (`SystemDictionaryShared::_saved_cpcache_entries_table`) that remembers the initial state of a `ConstantPoolCache` during CDS dumping. This table is indexed with a `ConstantPoolCache*` >> >> However, `ConstantPoolCache` has a complex lifecycle, especially with class redefinition. This makes it difficult to clean up the table. The crash reported in [the current bug](https://bugs.openjdk.org/browse/JDK-8292318) happened during clean up, probably because an `InstanceKlass` was still valid but its `ConstantPool` or `ConstantPoolCache` were not. >> >> For simplification, I am now storing the information inside the `ConstantPoolCache`. To compensate for the extra space used, I moved two 32-bit integers next to each other, so the net change in size is zero. >> >> instanceKlass.cpp was reverted to the state before #9759. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @calvinccheung review comments Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9887 From ccheung at openjdk.org Fri Aug 19 22:20:39 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 19 Aug 2022 22:20:39 GMT Subject: RFR: 8292318: Memory corruption in remove_dumptime_info [v2] In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 01:15:43 GMT, Ioi Lam wrote: >> src/hotspot/share/oops/cpCache.cpp line 722: >> >>> 720: #if INCLUDE_CDS >>> 721: MetadataFactory::free_array(data, _initial_entries); >>> 722: _initial_entries = NULL; >> >> Should the above be inside the following condition like before? >> >> `if (Arguments::is_dumping_archive()) {` > > I added a more strict check -- since _initial_entries is set only during CDS dump time, I added an assert that if _initial_entries is non NULL, we must be dumping. The non NULL check is good. ------------- PR: https://git.openjdk.org/jdk/pull/9887 From kvn at openjdk.org Fri Aug 19 23:30:50 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 19 Aug 2022 23:30:50 GMT Subject: RFR: 8292628: x86: Improve handling of constants in trigonometric stubs [v3] In-Reply-To: <9hAvoERJGWeVIjHqbtDBieCerZxSb1j8MtxmrJ8FDzw=.3d38a8c4-e088-4d5c-a449-6dc752e36e8b@github.com> References: <9hAvoERJGWeVIjHqbtDBieCerZxSb1j8MtxmrJ8FDzw=.3d38a8c4-e088-4d5c-a449-6dc752e36e8b@github.com> Message-ID: On Fri, 19 Aug 2022 17:53:08 GMT, Vladimir Ivanov wrote: >> Improve how constants are handled in trigonometric stubs on x86. >> In particular, extract shared constants into a separate file and >> encapsulate them in MacroAssembler. >> >> Also, some minor cleanups included. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 >> - [x] x86_32 build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > cleanups Seems fine to me. Thank you for doing this cleanup. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9923 From vlivanov at openjdk.org Sat Aug 20 00:38:37 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 20 Aug 2022 00:38:37 GMT Subject: RFR: 8292628: x86: Improve handling of constants in trigonometric stubs [v3] In-Reply-To: <9hAvoERJGWeVIjHqbtDBieCerZxSb1j8MtxmrJ8FDzw=.3d38a8c4-e088-4d5c-a449-6dc752e36e8b@github.com> References: <9hAvoERJGWeVIjHqbtDBieCerZxSb1j8MtxmrJ8FDzw=.3d38a8c4-e088-4d5c-a449-6dc752e36e8b@github.com> Message-ID: On Fri, 19 Aug 2022 17:53:08 GMT, Vladimir Ivanov wrote: >> Improve how constants are handled in trigonometric stubs on x86. >> In particular, extract shared constants into a separate file and >> encapsulate them in MacroAssembler. >> >> Also, some minor cleanups included. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 >> - [x] x86_32 build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > cleanups Thanks for the reviews, Aleksey and Vladimir. ------------- PR: https://git.openjdk.org/jdk/pull/9923 From vlivanov at openjdk.org Sat Aug 20 00:41:59 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 20 Aug 2022 00:41:59 GMT Subject: Integrated: 8292628: x86: Improve handling of constants in trigonometric stubs In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 16:52:36 GMT, Vladimir Ivanov wrote: > Improve how constants are handled in trigonometric stubs on x86. > In particular, extract shared constants into a separate file and > encapsulate them in MacroAssembler. > > Also, some minor cleanups included. > > Testing: > - [x] hs-tier1 - hs-tier4 > - [x] x86_32 build This pull request has now been integrated. Changeset: 44532009 Author: Vladimir Ivanov URL: https://git.openjdk.org/jdk/commit/44532009fff11884aa6f16a997b771c41cb01d2f Stats: 878 lines in 14 files changed: 323 ins; 450 del; 105 mod 8292628: x86: Improve handling of constants in trigonometric stubs Reviewed-by: shade, kvn ------------- PR: https://git.openjdk.org/jdk/pull/9923 From vlivanov at openjdk.org Sat Aug 20 01:13:19 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 20 Aug 2022 01:13:19 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v4] In-Reply-To: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: > (PR depends on #9923.) > > Constants which reside outside code cache are not guaranteed to be reachable in > RIP-relative addressing mode from stub code, but absolute addressing mode requires a > scratch register. > > Provide a scratch register to ensure constants are reachable irrespective of > process memory layout. > > Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. > > Testing: > - [x] hs-tier1 - hs-tier4 > - [x] x86_32 hotspot build Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into trig_rscratch - rscratch - cmp64 - 8292638: x86: Improve scratch register handling in VM stubs - StubRoutines cleanup - tabs - x86: Improve handling of constants in trigonometric stubs ------------- Changes: https://git.openjdk.org/jdk/pull/9932/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=03 Stats: 427 lines in 13 files changed: 69 ins; 98 del; 260 mod Patch: https://git.openjdk.org/jdk/pull/9932.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9932/head:pull/9932 PR: https://git.openjdk.org/jdk/pull/9932 From stuefe at openjdk.org Sat Aug 20 06:19:30 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 20 Aug 2022 06:19:30 GMT Subject: RFR: JDK-8292351: tty should always live [v4] In-Reply-To: References: Message-ID: <9C366Uo3shJ6XE-onK-ZrO_n4hG7MQf8OtiMQUZddZ4=.e622edd1-5738-47b9-b63b-ec5e44f5c14a@github.com> On Fri, 19 Aug 2022 12:48:19 GMT, Coleen Phillimore wrote: > I think this is fine as a last chance handler. If we do need pre-init and post-exit logging, ie things come out to this output, we can re-evaluate and move the defaultStream destructor later or have some pre-init logging functionality. This seems good for reliably getting bug reports but should rarely be needed. If you find otherwise, please file an RFE. Thank you Coleen. Thanks for the approval! David wanted to have some changes though, therefore I need to reform the patch a bit. In case you have not been following this really long review thread, this RFE has been triggered by an actual problem David had, where NMT found a C-heap corruption and tried to tell him but fell over tty=NULL during reporting. Cheers, THomas ------------- PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Sat Aug 20 07:17:32 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 20 Aug 2022 07:17:32 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v10] In-Reply-To: References: <9mcfdbIIegUsWvi568bllDXbwVJgz2ttRZ_qanqntIw=.9b081f46-3370-4380-86de-ea1f372fdf32@github.com> <92O7ygNu0UfHUfRaFp3KuNQ5PQe3tf2AGmDRXwgwRAg=.641f4e87-9c75-4e2f-8c81-fb9a32372c32@github.com> <7PP7QsJ9FmXSuiWlnM8nahCiLxuQA5rX25WW85Zs504=.a9c44739-e37f-422c-b014-77974d1a69a2@github.com> Message-ID: On Thu, 18 Aug 2022 15:46:04 GMT, Julian Waters wrote: > Initially I did intend to do that, but a raw GetLastError wouldn't exactly be very helpful when a failure does occur I disagree. Error codes are well documented, unlike posix errno with defined numerical values, and often more helpful than the localized error text. >, and unfortunately formatting the proper message from it takes quite a bit of ceremony (Thanks for nothing Win32 API!) Then factor that out into an utility function similar to strerror and use that as input to JLI_ReportErrorMessage. But again, only if it is worth the complexity. As long as there is not a single use case inside libjli we should not add this function. >that would hopefully be confined to only one function - And it seems so far that this one is quite a suitable candidate. To be sure, that RFE doesn't strictly require this one, and can be changed to use other utilities instead, but as mentioned above the same fault is in Windows error reporting routines all over the JDK, and unlike ReportErrorMessageSys which isn't used that often, those are very commonly used across the codebase, by doing that all we'd be doing is sidestepping the problem and leaving it to be fixed later. Yes. And that's fine. Please deal with one problem at a time, libjli in this case, and do a clearly defined solution that fits the problem in scope and complexity. Please follow the advice of reviewers, because you burn valuable reviewer time. > I did hope that a warning or outright refusal to concat the errors when either GetLastError and errno != 0 was a good solution, though I disagree. It is more confusing and not worth the added complexity. Look at it that way, at one hand you want to resolve errorcode and think raw errcode values are too much for the lay analyst, on the other hand you want to show him two potentially completely unrelated error texts, together with a cryptic warning, and let him figure out what that means? Let's do this simple and right. So far I have not seen a single use of this function inside the libjli codebase. So come up with that first as I wrote before. Then, if you see multiple use cases, we can maybe think of unifying code into a helper function. If there are no usages, just remove the function. ------------- PR: https://git.openjdk.org/jdk/pull/9870 From dnsimon at openjdk.org Sat Aug 20 14:51:43 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Sat, 20 Aug 2022 14:51:43 GMT Subject: RFR: 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter [v2] In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 13:26:34 GMT, Doug Simon wrote: >> [JDK-8282420](https://bugs.openjdk.org/browse/JDK-8282420) introduced the notion of "blessed methods" which are those that can link against `jdk.jfr.internal.event.EventWriterFactory.getEventWriter(long)`. >> This PR enhances the JVMCI ConstantPool API so that it can take a caller context when resolving a method to enforce this constraint properly. > > 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: > > support special linkage rules for jdk.jfr.internal.event.EventWriterFactory.getEventWriter(long) in JVMCI Still active. @mgronlun has indicated he will review it soon. ------------- PR: https://git.openjdk.org/jdk/pull/9449 From cstein at openjdk.org Sat Aug 20 16:15:13 2022 From: cstein at openjdk.org (Christian Stein) Date: Sat, 20 Aug 2022 16:15:13 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 Message-ID: Please review the change to update to using jtreg 7. The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Update to new JUnit JAR file - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Update github-actions.conf - JDK-8289798: Update to use jtreg 7 Changes: https://git.openjdk.org/jdk/pull/9393/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289798 Stats: 11 lines in 8 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/9393.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393 PR: https://git.openjdk.org/jdk/pull/9393 From alanb at openjdk.org Sat Aug 20 16:15:13 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 20 Aug 2022 16:15:13 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. Have you run all the tiers to make sure there aren't any issues? ------------- PR: https://git.openjdk.org/jdk/pull/9393 From cstein at openjdk.org Sat Aug 20 16:15:13 2022 From: cstein at openjdk.org (Christian Stein) Date: Sat, 20 Aug 2022 16:15:13 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. No. I'll mark this PR ready for review when all tiers ran successfully. Besides the usual bug fixes, updates, and minor improvements (see [changes since jtreg 6.2](https://github.com/openjdk/jtreg/compare/jtreg-6.2+1...jtreg-7+1)) the sole major new feature of jtreg 7 is: - Run tests annotated with `@run junit` via JUnit Platform's Launcher (version `1.8.2`). This enables writing tests using the Jupiter API (version `5.8.2`) in addition to writing and running JUnit 4-based tests. The change in `junit.java` will be superseded by https://github.com/openjdk/jdk/pull/9944 which deletes that file. ------------- PR: https://git.openjdk.org/jdk/pull/9393 From jpai at openjdk.org Sat Aug 20 16:15:13 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 20 Aug 2022 16:15:13 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 In-Reply-To: References: Message-ID: <9wOkjC3Cf252C2NCyfb32M5czLcyBK7lqHlKGD_qtaA=.5337fe86-04d6-4e8f-82e5-0e0b074210c3@github.com> On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. Hello Christian, more out of curiosity - what are some of the changes that jtreg 7 brings in? ------------- PR: https://git.openjdk.org/jdk/pull/9393 From kbarrett at openjdk.org Sat Aug 20 18:03:40 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 20 Aug 2022 18:03:40 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v2] In-Reply-To: References: <_S9kQ9tERdyaDhx4uRln5RqhOwNybDYJh8-Clso4OzA=.50ed9ac7-439d-4093-b1c6-5f3c3935a6a5@github.com> <_LOHkowYpfncG7PUHZXISOQRY5kW02UTF4SYRl9VM9k=.51cc43aa-5969-4469-a4c6-1f18c204d9a3@github.com> Message-ID: On Fri, 19 Aug 2022 21:05:19 GMT, David Holmes wrote: >> I don't now if your zlock is even a standard runtime/mutex, but let's definitely not have another version of lockers. I've never pushed back on blah_locked(). I need to see more evidence of why we need null mutex in the code (after the sweeper is removed), before I suggest a policy change. >> I have a patch that removes the NULL ObjectLocker argument. I thought ObjectLocker was the only thing that took null until yesterday. > >> Alternatively, we could have two versions of lockers to appease both sides? > > "They who cannot remember the past are condemned to repeat it." :) > > We used to have `MutexLockerEx` that allowed the NULL whereas `MutexLocker` did not. > > I have no issues with the NULL case as it is cleaner that defining locked and unlocked code paths. MutexLockerEx did two things - allow a nullptr for the mutex argument, and allow locking without a safepoint check. The vast majority of uses were for the latter. Both of those got merged into MutexLocker. (The old MutexLocker was deleted and MutexLockerEx was renamed to MutexLocker, with uses updated.) Perhaps only the safepoint check control should have been added to MutexLocker. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From iklam at openjdk.org Sun Aug 21 07:17:58 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 21 Aug 2022 07:17:58 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger Message-ID: Current in gdb, you can print information about a class or method with something like call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) However, it's difficult to find a class or method by its name and print out its contents. This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. - `findclass()`: class name only - `findmethod()`: class name and method name - `findmethod2()`: class name and method name/signature I also cleaned up `BytecodeTracer` to remove unnecessary complexity. (In future RFEs, I plan to add more detailed printing, such as the constant pool cache entry of resolved bootstrap methods). Here are some examples: (gdb) call findclass("java/lang/Object", 0) [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' (gdb) call findclass("java/lang/Object", 1) [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' 0x00007fffb4000658 : ()V 0x00007fffb40010f0 finalize : ()V 0x00007fffb4000f00 wait0 : (J)V 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z 0x00007fffb4000aa0 toString : ()Ljava/lang/String; 0x00007fffb40007f0 hashCode : ()I 0x00007fffb4000720 getClass : ()Ljava/lang/Class; 0x00007fffb40009a0 clone : ()Ljava/lang/Object; 0x00007fffb4000b50 notify : ()V 0x00007fffb4000c20 notifyAll : ()V 0x00007fffb4000e50 wait : (J)V 0x00007fffb4001028 wait : (JI)V 0x00007fffb4000d08 wait : ()V (gdb) call findclass("*ClassLoader", 0) [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' [....] (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' 0x00007fffb4000d08 wait : ()V 0x00007fffb4000ce8 0 fast_aload_0 0x00007fffb4000ce9 1 lconst_0 0x00007fffb4000cea 2 invokevirtual 38 0x00007fffb4000ced 5 return ------------- Commit messages: - 8292699: Improve printing of classes in native debugger Changes: https://git.openjdk.org/jdk/pull/9957/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292699 Stats: 346 lines in 11 files changed: 258 ins; 61 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/9957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9957/head:pull/9957 PR: https://git.openjdk.org/jdk/pull/9957 From stuefe at openjdk.org Sun Aug 21 07:21:23 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 21 Aug 2022 07:21:23 GMT Subject: RFR: JDK-8292351: tty should always live [v5] In-Reply-To: References: Message-ID: > The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. > > This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. > > tty should always be safe to write to, and that is trivial to do. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Compromise ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9874/files - new: https://git.openjdk.org/jdk/pull/9874/files/f119efc6..9d6a9082 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9874&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9874&range=03-04 Stats: 34 lines in 2 files changed: 23 ins; 3 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9874/head:pull/9874 PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Sun Aug 21 07:23:47 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 21 Aug 2022 07:23:47 GMT Subject: RFR: JDK-8292351: tty should always live [v4] In-Reply-To: <-CBcZdmJXMCg9oB6hPDibLhfMcgxw6U6QrjGsluK6_I=.192408c1-4111-4b3b-a882-f8e78115cffd@github.com> References: <-CBcZdmJXMCg9oB6hPDibLhfMcgxw6U6QrjGsluK6_I=.192408c1-4111-4b3b-a882-f8e78115cffd@github.com> Message-ID: <2cCn8Ret2Ccngh4-vmZzwa-XyP03Z2BxxZ343PW9myQ=.21f48007-8de1-435b-ad5e-bae1328bc1c4@github.com> On Fri, 19 Aug 2022 01:18:27 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Change comment > > Hi Thomas, > > I think for pre-init we would look at adding an env var (which would require a CSR request) when we actually have some logging we want to add. This PR could simply do the enabling for tty to be usable at that time ie set to stdout (as the default VM output destination). > > Your suggestion for post-exit seems reasonable, though we may also have to consider the flag that requests VM output get logged to a file (which we probably can't do). I think it reasonable that error and warning output go to stdout/stderr in post-exit. If other more general logging needed to be added for post-exit then that would be evaluated at the time. > > Thanks. @dholmes-ora : I reformed the patch according to our compromise: - pre-init output is swallowed, but we don't crash. We can add the envvar solution later if needed. - post-exit output is taken over by a stream that attempts to mimic the defaultStream's behavior. I did not find a VM flag to redirect defaultStream to a file. And we can still crash if concurrent threads attempt to use tty, but the window of opportunity is much smaller. I did not want to pull tty_lock though since I don't want to hold up VM shutdown in case of an error. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From iklam at openjdk.org Sun Aug 21 07:41:59 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 21 Aug 2022 07:41:59 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v2] In-Reply-To: References: Message-ID: > Current in gdb, you can print information about a class or method with something like > > > call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) > call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) > > > However, it's difficult to find a class or method by its name and print out its contents. > > This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. > > - `findclass()`: class name only > - `findmethod()`: class name and method name > - `findmethod2()`: class name and method name/signature > > I also cleaned up `BytecodeTracer` to remove unnecessary complexity. > > (In future RFEs, I plan to add more detailed printing, such as the constant pool cache entry of resolved bootstrap methods). > > Here are some examples: > > > (gdb) call findclass("java/lang/Object", 0) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > > (gdb) call findclass("java/lang/Object", 1) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000658 : ()V > 0x00007fffb40010f0 finalize : ()V > 0x00007fffb4000f00 wait0 : (J)V > 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z > 0x00007fffb4000aa0 toString : ()Ljava/lang/String; > 0x00007fffb40007f0 hashCode : ()I > 0x00007fffb4000720 getClass : ()Ljava/lang/Class; > 0x00007fffb40009a0 clone : ()Ljava/lang/Object; > 0x00007fffb4000b50 notify : ()V > 0x00007fffb4000c20 notifyAll : ()V > 0x00007fffb4000e50 wait : (J)V > 0x00007fffb4001028 wait : (JI)V > 0x00007fffb4000d08 wait : ()V > > (gdb) call findclass("*ClassLoader", 0) > [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [....] > > (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000d08 wait : ()V > 0x00007fffb4000ce8 0 fast_aload_0 > 0x00007fffb4000ce9 1 lconst_0 > 0x00007fffb4000cea 2 invokevirtual 38 > 0x00007fffb4000ced 5 return Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: match hidden class names ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9957/files - new: https://git.openjdk.org/jdk/pull/9957/files/242e2991..fdd2ef9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=00-01 Stats: 15 lines in 2 files changed: 12 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9957/head:pull/9957 PR: https://git.openjdk.org/jdk/pull/9957 From iklam at openjdk.org Sun Aug 21 15:59:50 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 21 Aug 2022 15:59:50 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v3] In-Reply-To: References: Message-ID: > Current in gdb, you can print information about a class or method with something like > > > call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) > call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) > > > However, it's difficult to find a class or method by its name and print out its contents. > > This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. > > - `findclass()`: class name only > - `findmethod()`: class name and method name > - `findmethod2()`: class name and method name/signature > > I also cleaned up `BytecodeTracer` to remove unnecessary complexity. > > (In future RFEs, I plan to add more detailed printing, such as the constant pool cache entry of resolved bootstrap methods). > > Here are some examples: > > > (gdb) call findclass("java/lang/Object", 0) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > > (gdb) call findclass("java/lang/Object", 1) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000658 : ()V > 0x00007fffb40010f0 finalize : ()V > 0x00007fffb4000f00 wait0 : (J)V > 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z > 0x00007fffb4000aa0 toString : ()Ljava/lang/String; > 0x00007fffb40007f0 hashCode : ()I > 0x00007fffb4000720 getClass : ()Ljava/lang/Class; > 0x00007fffb40009a0 clone : ()Ljava/lang/Object; > 0x00007fffb4000b50 notify : ()V > 0x00007fffb4000c20 notifyAll : ()V > 0x00007fffb4000e50 wait : (J)V > 0x00007fffb4001028 wait : (JI)V > 0x00007fffb4000d08 wait : ()V > > (gdb) call findclass("*ClassLoader", 0) > [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [....] > > (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000d08 wait : ()V > 0x00007fffb4000ce8 0 fast_aload_0 > 0x00007fffb4000ce9 1 lconst_0 > 0x00007fffb4000cea 2 invokevirtual 38 > 0x00007fffb4000ced 5 return Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed windows build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9957/files - new: https://git.openjdk.org/jdk/pull/9957/files/fdd2ef9a..4531af23 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9957/head:pull/9957 PR: https://git.openjdk.org/jdk/pull/9957 From duke at openjdk.org Sun Aug 21 16:18:11 2022 From: duke at openjdk.org (firefish01) Date: Sun, 21 Aug 2022 16:18:11 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v2] In-Reply-To: References: Message-ID: On Sun, 21 Aug 2022 07:41:59 GMT, Ioi Lam wrote: >> Current in gdb, you can print information about a class or method with something like >> >> >> call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) >> call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) >> >> >> However, it's difficult to find a class or method by its name and print out its contents. >> >> This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. >> >> - `findclass()`: class name only >> - `findmethod()`: class name and method name >> - `findmethod2()`: class name and method name/signature >> >> I also cleaned up `BytecodeTracer` to remove unnecessary complexity. >> >> (In future RFEs, I plan to add more detailed printing, such as the constant pool cache entry of resolved bootstrap methods). >> >> Here are some examples: >> >> >> (gdb) call findclass("java/lang/Object", 0) >> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' >> >> (gdb) call findclass("java/lang/Object", 1) >> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' >> 0x00007fffb4000658 : ()V >> 0x00007fffb40010f0 finalize : ()V >> 0x00007fffb4000f00 wait0 : (J)V >> 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z >> 0x00007fffb4000aa0 toString : ()Ljava/lang/String; >> 0x00007fffb40007f0 hashCode : ()I >> 0x00007fffb4000720 getClass : ()Ljava/lang/Class; >> 0x00007fffb40009a0 clone : ()Ljava/lang/Object; >> 0x00007fffb4000b50 notify : ()V >> 0x00007fffb4000c20 notifyAll : ()V >> 0x00007fffb4000e50 wait : (J)V >> 0x00007fffb4001028 wait : (JI)V >> 0x00007fffb4000d08 wait : ()V >> >> (gdb) call findclass("*ClassLoader", 0) >> [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' >> [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' >> [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' >> [....] >> >> (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) >> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' >> 0x00007fffb4000d08 wait : ()V >> 0x00007fffb4000ce8 0 fast_aload_0 >> 0x00007fffb4000ce9 1 lconst_0 >> 0x00007fffb4000cea 2 invokevirtual 38 >> 0x00007fffb4000ced 5 return > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > match hidden class names very good ------------- PR: https://git.openjdk.org/jdk/pull/9957 From iklam at openjdk.org Sun Aug 21 21:23:58 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 21 Aug 2022 21:23:58 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v4] In-Reply-To: References: Message-ID: > Current in gdb, you can print information about a class or method with something like > > > call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) > call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) > > > However, it's difficult to find a class or method by its name and print out its contents. > > This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. > > - `findclass()`: class name only > - `findmethod()`: class name and method name > - `findmethod2()`: class name and method name/signature > > I also cleaned up `BytecodeTracer` to remove unnecessary complexity. > > Here are some examples: > > > (gdb) call findclass("java/lang/Object", 0) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > > (gdb) call findclass("java/lang/Object", 1) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000658 : ()V > 0x00007fffb40010f0 finalize : ()V > 0x00007fffb4000f00 wait0 : (J)V > 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z > 0x00007fffb4000aa0 toString : ()Ljava/lang/String; > 0x00007fffb40007f0 hashCode : ()I > 0x00007fffb4000720 getClass : ()Ljava/lang/Class; > 0x00007fffb40009a0 clone : ()Ljava/lang/Object; > 0x00007fffb4000b50 notify : ()V > 0x00007fffb4000c20 notifyAll : ()V > 0x00007fffb4000e50 wait : (J)V > 0x00007fffb4001028 wait : (JI)V > 0x00007fffb4000d08 wait : ()V > > (gdb) call findclass("*ClassLoader", 0) > [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [....] > > (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000d08 wait : ()V > 0x00007fffb4000ce8 0 fast_aload_0 > 0x00007fffb4000ce9 1 lconst_0 > 0x00007fffb4000cea 2 invokevirtual 38 > 0x00007fffb4000ced 5 return Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Print more info for invokedynamic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9957/files - new: https://git.openjdk.org/jdk/pull/9957/files/4531af23..4b2dfc37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=02-03 Stats: 59 lines in 2 files changed: 58 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9957/head:pull/9957 PR: https://git.openjdk.org/jdk/pull/9957 From iklam at openjdk.org Sun Aug 21 21:23:58 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 21 Aug 2022 21:23:58 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v3] In-Reply-To: References: Message-ID: On Sun, 21 Aug 2022 15:59:50 GMT, Ioi Lam wrote: >> Current in gdb, you can print information about a class or method with something like >> >> >> call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) >> call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) >> >> >> However, it's difficult to find a class or method by its name and print out its contents. >> >> This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. >> >> - `findclass()`: class name only >> - `findmethod()`: class name and method name >> - `findmethod2()`: class name and method name/signature >> >> I also cleaned up `BytecodeTracer` to remove unnecessary complexity. >> >> Here are some examples: >> >> >> (gdb) call findclass("java/lang/Object", 0) >> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' >> >> (gdb) call findclass("java/lang/Object", 1) >> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' >> 0x00007fffb4000658 : ()V >> 0x00007fffb40010f0 finalize : ()V >> 0x00007fffb4000f00 wait0 : (J)V >> 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z >> 0x00007fffb4000aa0 toString : ()Ljava/lang/String; >> 0x00007fffb40007f0 hashCode : ()I >> 0x00007fffb4000720 getClass : ()Ljava/lang/Class; >> 0x00007fffb40009a0 clone : ()Ljava/lang/Object; >> 0x00007fffb4000b50 notify : ()V >> 0x00007fffb4000c20 notifyAll : ()V >> 0x00007fffb4000e50 wait : (J)V >> 0x00007fffb4001028 wait : (JI)V >> 0x00007fffb4000d08 wait : ()V >> >> (gdb) call findclass("*ClassLoader", 0) >> [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' >> [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' >> [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' >> [....] >> >> (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) >> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' >> 0x00007fffb4000d08 wait : ()V >> 0x00007fffb4000ce8 0 fast_aload_0 >> 0x00007fffb4000ce9 1 lconst_0 >> 0x00007fffb4000cea 2 invokevirtual 38 >> 0x00007fffb4000ced 5 return > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed windows build I added the ability to print out details for `invokedynamic` bytecodes. 0x00007fffb4500708 main : ([Ljava/lang/String;)V 0x00007fffb45006b8 0 invokedynamic bsm=104 7 BSM: REF_invokeStatic 105 arguments[3] = { 6 Symbol: '()V' count 65535 113 6 Symbol: '()V' count 65535 } ConstantPoolCacheEntry: 19 (0x00007fffb4500f80) [00|ba| 7] [ 0x00007fffb4427268] [ 0x000000000000000b] [ 0xffffffff83400001] ------------- Method: java/lang/invoke/Invokers$Holder.linkToTargetMethod(Ljava/lang/Object;)Ljava/lang/Object; appendix: java.lang.invoke.BoundMethodHandle$Species_L {0x000000062da8ab68} - klass: 'java/lang/invoke/BoundMethodHandle$Species_L' - ---- fields (total size 5 words): - private 'customizationCount' 'B' @12 0 - private volatile 'updateInProgress' 'Z' @13 false - private final 'type' 'Ljava/lang/invoke/MethodType;' @16 a 'java/lang/invoke/MethodType'{0x000000062da831f8} = ()Ljava/lang/Runnable; (c5b5063f) - final 'form' 'Ljava/lang/invoke/LambdaForm;' @20 a 'java/lang/invoke/LambdaForm'{0x000000062da8aa48} => a 'java/lang/invoke/MemberName'{0x000000062da8d948} = {method} {0x00007fffb4502278} 'invoke' '(Ljava/lang/Object;)Ljava/lang/Object;' in 'java/lang/invoke/LambdaForm$MH+0x0000000800000400' (c5b51549) - private 'asTypeCache' 'Ljava/lang/invoke/MethodHandle;' @24 NULL (0) - private 'asTypeSoftCache' 'Ljava/lang/ref/SoftReference;' @28 NULL (0) - final 'argL0' 'Ljava/lang/Object;' @32 a 'HelloLambda$$Lambda$2+0x0000000800000a18'{0x000000062da86120} (c5b50c24) 0x00007fffb45006bd 5 invokestatic 11 ------------- PR: https://git.openjdk.org/jdk/pull/9957 From iklam at openjdk.org Sun Aug 21 21:59:21 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 21 Aug 2022 21:59:21 GMT Subject: RFR: 8292318: Memory corruption in remove_dumptime_info [v4] In-Reply-To: References: Message-ID: > In [JDK-8290833](https://bugs.openjdk.org/browse/JDK-8290833) (#9759), I added a table (`SystemDictionaryShared::_saved_cpcache_entries_table`) that remembers the initial state of a `ConstantPoolCache` during CDS dumping. This table is indexed with a `ConstantPoolCache*` > > However, `ConstantPoolCache` has a complex lifecycle, especially with class redefinition. This makes it difficult to clean up the table. The crash reported in [the current bug](https://bugs.openjdk.org/browse/JDK-8292318) happened during clean up, probably because an `InstanceKlass` was still valid but its `ConstantPool` or `ConstantPoolCache` were not. > > For simplification, I am now storing the information inside the `ConstantPoolCache`. To compensate for the extra space used, I moved two 32-bit integers next to each other, so the net change in size is zero. > > instanceKlass.cpp was reverted to the state before #9759. 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' of https://github.com/openjdk/jdk into 8292318-memory-corruption-in-remove-dumptime-info-ver2 - @calvinccheung review comments - added comments about what _initial_entries points to - fixed old bug in test case - 8292318: Memory corruption in remove_dumptime_info ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9887/files - new: https://git.openjdk.org/jdk/pull/9887/files/d69ab667..786fb685 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9887&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9887&range=02-03 Stats: 40064 lines in 404 files changed: 17651 ins; 20464 del; 1949 mod Patch: https://git.openjdk.org/jdk/pull/9887.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9887/head:pull/9887 PR: https://git.openjdk.org/jdk/pull/9887 From iklam at openjdk.org Sun Aug 21 22:02:34 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 21 Aug 2022 22:02:34 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v5] In-Reply-To: References: Message-ID: > Current in gdb, you can print information about a class or method with something like > > > call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) > call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) > > > However, it's difficult to find a class or method by its name and print out its contents. > > This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. > > - `findclass()`: class name only > - `findmethod()`: class name and method name > - `findmethod2()`: class name and method name/signature > > I also cleaned up `BytecodeTracer` to remove unnecessary complexity. > > Here are some examples: > > > (gdb) call findclass("java/lang/Object", 0) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > > (gdb) call findclass("java/lang/Object", 1) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000658 : ()V > 0x00007fffb40010f0 finalize : ()V > 0x00007fffb4000f00 wait0 : (J)V > 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z > 0x00007fffb4000aa0 toString : ()Ljava/lang/String; > 0x00007fffb40007f0 hashCode : ()I > 0x00007fffb4000720 getClass : ()Ljava/lang/Class; > 0x00007fffb40009a0 clone : ()Ljava/lang/Object; > 0x00007fffb4000b50 notify : ()V > 0x00007fffb4000c20 notifyAll : ()V > 0x00007fffb4000e50 wait : (J)V > 0x00007fffb4001028 wait : (JI)V > 0x00007fffb4000d08 wait : ()V > > (gdb) call findclass("*ClassLoader", 0) > [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [....] > > (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000d08 wait : ()V > 0x00007fffb4000ce8 0 fast_aload_0 > 0x00007fffb4000ce9 1 lconst_0 > 0x00007fffb4000cea 2 invokevirtual 38 > 0x00007fffb4000ced 5 return Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: also print Method pointer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9957/files - new: https://git.openjdk.org/jdk/pull/9957/files/4b2dfc37..1b64ee06 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9957/head:pull/9957 PR: https://git.openjdk.org/jdk/pull/9957 From iklam at openjdk.org Mon Aug 22 03:46:41 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 22 Aug 2022 03:46:41 GMT Subject: RFR: 8292318: Memory corruption in remove_dumptime_info [v3] In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 22:18:11 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @calvinccheung review comments > > Marked as reviewed by ccheung (Reviewer). Thanks for the review @calvinccheung @coleenp ------------- PR: https://git.openjdk.org/jdk/pull/9887 From iklam at openjdk.org Mon Aug 22 03:46:43 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 22 Aug 2022 03:46:43 GMT Subject: Integrated: 8292318: Memory corruption in remove_dumptime_info In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 03:48:49 GMT, Ioi Lam wrote: > In [JDK-8290833](https://bugs.openjdk.org/browse/JDK-8290833) (#9759), I added a table (`SystemDictionaryShared::_saved_cpcache_entries_table`) that remembers the initial state of a `ConstantPoolCache` during CDS dumping. This table is indexed with a `ConstantPoolCache*` > > However, `ConstantPoolCache` has a complex lifecycle, especially with class redefinition. This makes it difficult to clean up the table. The crash reported in [the current bug](https://bugs.openjdk.org/browse/JDK-8292318) happened during clean up, probably because an `InstanceKlass` was still valid but its `ConstantPool` or `ConstantPoolCache` were not. > > For simplification, I am now storing the information inside the `ConstantPoolCache`. To compensate for the extra space used, I moved two 32-bit integers next to each other, so the net change in size is zero. > > instanceKlass.cpp was reverted to the state before #9759. This pull request has now been integrated. Changeset: 27b0f772 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/27b0f7726b70127c0ed714cfc1041d3da71a9dc3 Stats: 108 lines in 7 files changed: 23 ins; 69 del; 16 mod 8292318: Memory corruption in remove_dumptime_info Reviewed-by: coleenp, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/9887 From kbarrett at openjdk.org Mon Aug 22 05:06:28 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 22 Aug 2022 05:06:28 GMT Subject: RFR: 8292671: Hotspot Style Guide should allow covariant returns In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 14:12:05 GMT, Roland Westrelin wrote: > The style guide explicitly lists covariant returns as a disallowed > feature of c++. I propose we allow that feature. > > This came up on the c2 side where, with JDK-8275201, I introduced some > uses of covariant returns at a number of locations in the c2 code > because I felt the code was cleaner that way. I wasn't aware it was > mentioned on the style guide. This was noticed by another openjdk > contributor and I prepared a change to revert the use of covariant > returns I had introduced: > > https://github.com/openjdk/jdk/pull/9237 > > But it feels that change actually makes the code less clear and > comments on the PR indicates some other contributors feel the same > way. > > It's unclear to me why covariant returns are disallowed in the first > place and the (few) contributors I asked don't seem to know either. So > I propose simply allowing covariant returns. Marked as reviewed by kbarrett (Reviewer). doc/hotspot-style.md line 1073: > 1071: ([n2544](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf)) > 1072: > 1073: * Covariant return types Covariant return types are a C++03 feature, so are covered by the blanket permission for such here: https://github.com/openjdk/jdk/blame/master/doc/hotspot-style.md#L385-L386 So the exclusion could be just deleted, rather than changing to explicit permission. Though an argument for explicit permission is to make the removal of the long-standing exclusion more obvious. I'm fine with either, but thought it was worth mentioning. ------------- PR: https://git.openjdk.org/jdk/pull/9941 From iklam at openjdk.org Mon Aug 22 05:29:02 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 22 Aug 2022 05:29:02 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v6] In-Reply-To: References: Message-ID: > Current in gdb, you can print information about a class or method with something like > > > call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) > call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) > > > However, it's difficult to find a class or method by its name and print out its contents. > > This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. > > - `findclass()`: class name only > - `findmethod()`: class name and method name > - `findmethod2()`: class name and method name/signature > > I also cleaned up `BytecodeTracer` to remove unnecessary complexity. > > Here are some examples: > > > (gdb) call findclass("java/lang/Object", 0) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > > (gdb) call findclass("java/lang/Object", 1) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000658 : ()V > 0x00007fffb40010f0 finalize : ()V > 0x00007fffb4000f00 wait0 : (J)V > 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z > 0x00007fffb4000aa0 toString : ()Ljava/lang/String; > 0x00007fffb40007f0 hashCode : ()I > 0x00007fffb4000720 getClass : ()Ljava/lang/Class; > 0x00007fffb40009a0 clone : ()Ljava/lang/Object; > 0x00007fffb4000b50 notify : ()V > 0x00007fffb4000c20 notifyAll : ()V > 0x00007fffb4000e50 wait : (J)V > 0x00007fffb4001028 wait : (JI)V > 0x00007fffb4000d08 wait : ()V > > (gdb) call findclass("*ClassLoader", 0) > [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [....] > > (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000d08 wait : ()V > 0x00007fffb4000ce8 0 fast_aload_0 > 0x00007fffb4000ce9 1 lconst_0 > 0x00007fffb4000cea 2 invokevirtual 38 > 0x00007fffb4000ced 5 return Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - Do not use class external name in printing - Added detailed printing of invokehandle ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9957/files - new: https://git.openjdk.org/jdk/pull/9957/files/1b64ee06..6c529f8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=04-05 Stats: 117 lines in 3 files changed: 48 ins; 28 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/9957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9957/head:pull/9957 PR: https://git.openjdk.org/jdk/pull/9957 From stuefe at openjdk.org Mon Aug 22 05:31:39 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 22 Aug 2022 05:31:39 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v5] In-Reply-To: References: Message-ID: On Sun, 21 Aug 2022 22:02:34 GMT, Ioi Lam wrote: >> Current in gdb, you can print information about a class or method with something like >> >> >> call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) >> call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) >> >> >> However, it's difficult to find a class or method by its name and print out its contents. >> >> This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. >> >> - `findclass()`: class name only >> - `findmethod()`: class name and method name >> - `findmethod2()`: class name and method name/signature >> >> I also cleaned up `BytecodeTracer` to remove unnecessary complexity. >> >> Here are some examples: >> >> >> (gdb) call findclass("java/lang/Object", 0) >> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' >> >> (gdb) call findclass("java/lang/Object", 1) >> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' >> 0x00007fffb4000658 : ()V >> 0x00007fffb40010f0 finalize : ()V >> 0x00007fffb4000f00 wait0 : (J)V >> 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z >> 0x00007fffb4000aa0 toString : ()Ljava/lang/String; >> 0x00007fffb40007f0 hashCode : ()I >> 0x00007fffb4000720 getClass : ()Ljava/lang/Class; >> 0x00007fffb40009a0 clone : ()Ljava/lang/Object; >> 0x00007fffb4000b50 notify : ()V >> 0x00007fffb4000c20 notifyAll : ()V >> 0x00007fffb4000e50 wait : (J)V >> 0x00007fffb4001028 wait : (JI)V >> 0x00007fffb4000d08 wait : ()V >> >> (gdb) call findclass("*ClassLoader", 0) >> [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' >> [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' >> [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' >> [....] >> >> (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) >> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' >> 0x00007fffb4000d08 wait : ()V >> 0x00007fffb4000ce8 0 fast_aload_0 >> 0x00007fffb4000ce9 1 lconst_0 >> 0x00007fffb4000cea 2 invokevirtual 38 >> 0x00007fffb4000ced 5 return > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > also print Method pointer Hi Ioi, this looks neat. Not a full review, just some remarks: - Not your patch, but while playing with this I found that "call help()" needs a RM, which means gdb crashes out in a non-attached thread (e.g. the primordial one). Would be nice if no RM were needed. - Calling "findclass" from a java thread yielded this: (gdb) call findclass("*", 7) [Thread 0x7fffb28cf700 (LWP 112211) exited] "Executing findclass" Thread 2 "java" received signal SIGSEGV, Segmentation fault. 0x00007ffff6fe17ba in assert_locked_or_safepoint (lock=0x7ffff0027320) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/runtime/mutexLocker.cpp:178 178 fatal("must own lock %s", lock->name()); The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on". Evaluation of the expression containing the function (findclass(char const*, int)) will be abandoned. When the function is done executing, GDB will silently stop. (gdb) bt #0 0x00007ffff6fe17ba in assert_locked_or_safepoint (lock=0x7ffff0027320) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/runtime/mutexLocker.cpp:178 #1 assert_locked_or_safepoint (lock=0x7ffff0027320) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/runtime/mutexLocker.cpp:172 #2 0x00007ffff639dcfb in ClassLoaderDataGraphIteratorBase::ClassLoaderDataGraphIteratorBase (this=0x7ffff57b3390) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/runtime/handles.hpp:263 #3 ClassLoaderDataGraph::classes_do (klass_closure=klass_closure at entry=0x7ffff57b3420) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/classLoaderDataGraph.cpp:366 #4 0x00007ffff63acbe0 in ClassPrinter::print_classes_unlocked (class_name_pattern=class_name_pattern at entry=0x7ffff7d5de80 "*", flags=flags at entry=7) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/classPrinter.cpp:139 #5 0x00007ffff64ebda9 in findclass (class_name_pattern=0x7ffff7d5de80 "*", flags=7) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/utilities/debug.cpp:647 #6 #7 __GI___libc_read (nbytes=8192, buf=0x7ffff57b3600, fd=0) at ../sysdeps/unix/sysv/linux/read.c:26 #8 __GI___libc_read (fd=fd at entry=0, buf=buf at entry=0x7ffff57b3600, nbytes=nbytes at entry=8192) at ../sysdeps/unix/sysv/linux/read.c:24 #9 0x00007ffff5682038 in read (__nbytes=8192, __buf=0x7ffff57b3600, __fd=0) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44 #10 handleRead (fd=fd at entry=0, buf=buf at entry=0x7ffff57b3600, len=len at entry=8192) at /shared/projects/openjdk/jdk-jdk/source/src/java.base/unix/native/libjava/io_util_md.c:188 #11 0x00007ffff568178c in readBytes (env=0x7ffff0029170, this=, bytes=0x7ffff57b56e8, off=0, len=8192, fid=) at /shared/projects/openjdk/jdk-jdk/source/src/java.base/share/native/libjava/io_util.c:109 #12 0x00007fffe01eaf50 in ?? () #13 0x0000000000000040 in ?? () #14 0x00007ffff0028e50 in ?? () #15 0x00007fffa802f620 in ?? () ``` - You could add a simple test at least as gtests, looking for some well-known classes. - instead of using int for flags, maybe use an enum class and define the bitwise combine operator? Like this: enum class Mode : int { PRINT_METHOD_NAME = 1 << 0, PRINT_BYTECODE = 1 << 1, PRINT_BYTECODE_ADDR = 1 << 2, PRINT_DYNAMIC = 1 << 3, // extra information for invokedynamic (and dynamic constant ...) }; constexpr enum Mode operator | (enum Mode selfValue, enum Mode inValue) { return (Mode)(uint32_t(selfValue) | uint32_t(inValue)); } Cheers, Thomas src/hotspot/share/classfile/classPrinter.hpp line 59: > 57: }; > 58: > 59: // flags must be OR'ed from ClassPrinter::Mode for the next 3 functions Can you give us a mode PRINT_ALL that or'es all of them modes together, and make that maybe the default for flags? ------------- PR: https://git.openjdk.org/jdk/pull/9957 From stuefe at openjdk.org Mon Aug 22 05:34:19 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 22 Aug 2022 05:34:19 GMT Subject: RFR: 8292671: Hotspot Style Guide should allow covariant returns In-Reply-To: References: Message-ID: <22mPTjF88YXv3yQFXIuaiVTVRIY5C1Yp2QQzEz3hKrs=.f49a8b96-dc8e-49f5-843a-dcef61771857@github.com> On Fri, 19 Aug 2022 14:12:05 GMT, Roland Westrelin wrote: > The style guide explicitly lists covariant returns as a disallowed > feature of c++. I propose we allow that feature. > > This came up on the c2 side where, with JDK-8275201, I introduced some > uses of covariant returns at a number of locations in the c2 code > because I felt the code was cleaner that way. I wasn't aware it was > mentioned on the style guide. This was noticed by another openjdk > contributor and I prepared a change to revert the use of covariant > returns I had introduced: > > https://github.com/openjdk/jdk/pull/9237 > > But it feels that change actually makes the code less clear and > comments on the PR indicates some other contributors feel the same > way. > > It's unclear to me why covariant returns are disallowed in the first > place and the (few) contributors I asked don't seem to know either. So > I propose simply allowing covariant returns. This makes sense. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/9941 From dholmes at openjdk.org Mon Aug 22 08:00:34 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Aug 2022 08:00:34 GMT Subject: RFR: JDK-8292351: tty should always live [v5] In-Reply-To: References: Message-ID: On Sun, 21 Aug 2022 07:21:23 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Compromise One minor issue below but otherwise this seems like a good compromise. Thanks. src/hotspot/share/utilities/ostream.cpp line 432: > 430: // The policy followed here is a compromise reached during review of JDK-8292351: > 431: // - pre-init: we silently swallow all output. We won't see anything, but at least won't crash > 432: // - post-exit: we write to a simple fdStream, but somewhat mimik the behavior of the real defaultStream s/mimik/mimic/ src/hotspot/share/utilities/ostream.cpp line 982: > 980: delete tty; > 981: } > 982: tty = DisplayVMOutputToStderr ? fdStream::stdout_stream() : fdStream::stderr_stream(); Shouldn't this be something like: tmp = tty; tty = ... delete tmp; ------------- PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Mon Aug 22 08:06:26 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 22 Aug 2022 08:06:26 GMT Subject: RFR: JDK-8292351: tty should always live [v5] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 07:55:17 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Compromise > > src/hotspot/share/utilities/ostream.cpp line 982: > >> 980: delete tty; >> 981: } >> 982: tty = DisplayVMOutputToStderr ? fdStream::stdout_stream() : fdStream::stderr_stream(); > > Shouldn't this be something like: > > tmp = tty; > tty = ... > delete tmp; It probably does not make much difference since the swap-over is not atomic anyway, but I can change it. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From ihse at openjdk.org Mon Aug 22 09:46:29 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 22 Aug 2022 09:46:29 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. I think the configure script should verify that we got the minimum jtreg needed. This is not really related to the change, but seeing this PR got me thinking about it. I also think a change such as this might bite people who have local setups with older jtreg installations, and then it would be nice for it to fail early in configure. If you are interested in including such a check, I could contribute the code for the configure script. I just want to check one thing: I see there are multiple `requiredVersion` in different TEST.ROOT files. Does this new requirement apply to *all* our jtreg tests? ------------- PR: https://git.openjdk.org/jdk/pull/9393 From duke at openjdk.org Mon Aug 22 11:02:01 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 22 Aug 2022 11:02:01 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way Message-ID: This PR removes a lot of boilerplate that was required when creating multi-threaded tests and ports 2 tests to show that the number of lines of code is significantly reduced and that porting is fairly trivial. The ported tests also serve as an introduction to others who're looking into writing their own multi-threaded tests. Testing: Ran the ported tests on my machine, also running the tests on x64 {Windows, Linux, Mac OS X], aarch64 { Linux, Mac OS X} and tier1 for "completeness". ------------- Commit messages: - Implement new thread helpers Changes: https://git.openjdk.org/jdk/pull/9962/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9962&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292679 Stats: 199 lines in 3 files changed: 80 ins; 73 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/9962.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9962/head:pull/9962 PR: https://git.openjdk.org/jdk/pull/9962 From ihse at openjdk.org Mon Aug 22 11:36:31 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 22 Aug 2022 11:36:31 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 In-Reply-To: References: Message-ID: <84r0tcH3qGIH6INXsFU0NSEe1cpkrs4SucSnj5WNtkA=.f02c5997-449c-4302-aaaa-ae3a4b5b3c02@github.com> On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. Actually, lets do that separately. I opened https://bugs.openjdk.org/browse/JDK-8292716. ------------- PR: https://git.openjdk.org/jdk/pull/9393 From shade at openjdk.org Mon Aug 22 11:36:40 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 22 Aug 2022 11:36:40 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v4] In-Reply-To: References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: On Sat, 20 Aug 2022 01:13:19 GMT, Vladimir Ivanov wrote: >> (PR depends on #9923.) >> >> Constants which reside outside code cache are not guaranteed to be reachable in >> RIP-relative addressing mode from stub code, but absolute addressing mode requires a >> scratch register. >> >> Provide a scratch register to ensure constants are reachable irrespective of >> process memory layout. >> >> Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 >> - [x] x86_32 hotspot build > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into trig_rscratch > - rscratch > - cmp64 > - 8292638: x86: Improve scratch register handling in VM stubs > - StubRoutines cleanup > - tabs > - x86: Improve handling of constants in trigonometric stubs Some review comments. Let me run x86_32 tests real quick. src/hotspot/cpu/x86/assembler_x86.cpp line 12240: > 12238: if (!is_reachable) { > 12239: assert(!always_reachable(adr), "sanity"); > 12240: } Maybe a bit cleaner like this: Suggestion: assert(is_reachable || !always_reachable(adr), "sanity"); src/hotspot/cpu/x86/assembler_x86.cpp line 12244: > 12242: } > 12243: > 12244: bool Assembler::always_reachable(AddressLiteral adr) { So, there is a similar block in `Assembler::is_reachable_from` -- does it make sense to reuse it then? They also are subtly different on the use of `ForceUnreachable`, would this method return different result compared to `Assembler::is_reachable_from`, and thus fail the assert in `Assembler::reachable`? src/hotspot/cpu/x86/macroAssembler_x86.cpp line 525: > 523: void MacroAssembler::cmp64(Register src1, AddressLiteral src2, Register rscratch) { > 524: assert(!src2.is_lval(), "should use cmpptr"); > 525: assert(rscratch != noreg || always_reachable(src2), "missing"); Here and later, redundant double space before "missing". src/hotspot/cpu/x86/macroAssembler_x86.hpp line 1272: > 1270: void movsd(Address dst, XMMRegister src) { Assembler::movsd(dst, src); } > 1271: void movsd(XMMRegister dst, XMMRegister src) { Assembler::movsd(dst, src); } > 1272: void movsd(XMMRegister dst, Address src) { Assembler::movsd(dst, src); } Minor misindent introduced. ------------- PR: https://git.openjdk.org/jdk/pull/9932 From rehn at openjdk.org Mon Aug 22 11:56:35 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 22 Aug 2022 11:56:35 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 10:53:27 GMT, Johan Sj?l?n wrote: > This PR removes a lot of boilerplate that was required when creating multi-threaded tests and ports 2 tests to show that the number of lines of code is significantly reduced and that porting is fairly trivial. The ported tests also serve as an introduction to others who're looking into writing their own multi-threaded tests. > > Testing: Ran the ported tests on my machine, also running the tests on x64 {Windows, Linux, Mac OS X], aarch64 { Linux, Mac OS X} and tier1 for "completeness". Thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9962 From coleenp at openjdk.org Mon Aug 22 12:42:32 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 22 Aug 2022 12:42:32 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 10:53:27 GMT, Johan Sj?l?n wrote: > This PR removes a lot of boilerplate that was required when creating multi-threaded tests and ports 2 tests to show that the number of lines of code is significantly reduced and that porting is fairly trivial. The ported tests also serve as an introduction to others who're looking into writing their own multi-threaded tests. > > Testing: Ran the ported tests on my machine, also running the tests on x64 {Windows, Linux, Mac OS X], aarch64 { Linux, Mac OS X} and tier1 for "completeness". I like this change a lot! test/hotspot/gtest/utilities/test_globalCounter.cpp line 64: > 62: [&]() { > 63: return &test; > 64: }); Can you format the Symbol case like this? makes it easier to parse the syntax and match the ()s. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/9962 From shade at openjdk.org Mon Aug 22 12:45:32 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 22 Aug 2022 12:45:32 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v4] In-Reply-To: References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: On Sat, 20 Aug 2022 01:13:19 GMT, Vladimir Ivanov wrote: >> (PR depends on #9923.) >> >> Constants which reside outside code cache are not guaranteed to be reachable in >> RIP-relative addressing mode from stub code, but absolute addressing mode requires a >> scratch register. >> >> Provide a scratch register to ensure constants are reachable irrespective of >> process memory layout. >> >> Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 >> - [x] x86_32 hotspot build > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into trig_rscratch > - rscratch > - cmp64 > - 8292638: x86: Improve scratch register handling in VM stubs > - StubRoutines cleanup > - tabs > - x86: Improve handling of constants in trigonometric stubs x86_32 tier1 is good. Here is the patch that does the symmetric changes in `stubGenerator_x86_64.cpp`: https://cr.openjdk.java.net/~shade/8292638/x86-add-1.patch ------------- PR: https://git.openjdk.org/jdk/pull/9932 From mgronlun at openjdk.org Mon Aug 22 14:08:33 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 22 Aug 2022 14:08:33 GMT Subject: RFR: 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter [v2] In-Reply-To: References: Message-ID: <7DEFTa_zfIGOoJohomBvwb4SPIspQ7mmkX6DSPPy1t8=.85c35e14-6b2c-4168-bfd0-08dce581e233@github.com> On Mon, 11 Jul 2022 13:26:34 GMT, Doug Simon wrote: >> [JDK-8282420](https://bugs.openjdk.org/browse/JDK-8282420) introduced the notion of "blessed methods" which are those that can link against `jdk.jfr.internal.event.EventWriterFactory.getEventWriter(long)`. >> This PR enhances the JVMCI ConstantPool API so that it can take a caller context when resolving a method to enforce this constraint properly. > > 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: > > support special linkage rules for jdk.jfr.internal.event.EventWriterFactory.getEventWriter(long) in JVMCI Hi Douglas, sorry for the delay in getting to this. The JFR-related changes look good. I can't really comment on the jvmci java classes in detail unfortunately but they look reasonable. Cheers. test/jdk/jdk/jfr/jvm/TestGetEventWriter.java line 102: > 100: } > 101: > 102: private static ResolvedJavaMethod findCommitMethod(MetaAccessProvider metaAccess, Class eventClass) { Can you please move all the JVMCI support stuff to the end of the file instead of the beginning? Only because it makes for easier reading for the non-JVMCI cases, thanks. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.org/jdk/pull/9449 From mgronlun at openjdk.org Mon Aug 22 14:08:35 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 22 Aug 2022 14:08:35 GMT Subject: RFR: 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter [v2] In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 11:14:52 GMT, Doug Simon wrote: >> 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: >> >> support special linkage rules for jdk.jfr.internal.event.EventWriterFactory.getEventWriter(long) in JVMCI > > test/jdk/jdk/jfr/jvm/TestGetEventWriter.java line 60: > >> 58: * @run main/othervm jdk.jfr.jvm.TestGetEventWriter >> 59: * >> 60: * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -Dtest.jvmci=true --add-exports=jdk.jfr/jdk.jfr.internal.event=ALL-UNNAMED > > I think `--add-exports=jdk.jfr/jdk.jfr.internal.event=ALL-UNNAMED` should be added to all `@run` specs in this test. See more details [here](https://github.com/openjdk/jdk/pull/8383#discussion_r915755771). We export certain modules and packages dynamically to the caller module when it registers an event. So don't think it is needed for those. ------------- PR: https://git.openjdk.org/jdk/pull/9449 From coleenp at openjdk.org Mon Aug 22 14:36:37 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 22 Aug 2022 14:36:37 GMT Subject: RFR: JDK-8292351: tty should always live [v5] In-Reply-To: References: Message-ID: On Sun, 21 Aug 2022 07:21:23 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Compromise Ok, this seems fine. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/9874 From dnsimon at openjdk.org Mon Aug 22 15:05:38 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 22 Aug 2022 15:05:38 GMT Subject: RFR: 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter [v2] In-Reply-To: <7DEFTa_zfIGOoJohomBvwb4SPIspQ7mmkX6DSPPy1t8=.85c35e14-6b2c-4168-bfd0-08dce581e233@github.com> References: <7DEFTa_zfIGOoJohomBvwb4SPIspQ7mmkX6DSPPy1t8=.85c35e14-6b2c-4168-bfd0-08dce581e233@github.com> Message-ID: On Mon, 22 Aug 2022 13:56:02 GMT, Markus Gr?nlund wrote: >> 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: >> >> support special linkage rules for jdk.jfr.internal.event.EventWriterFactory.getEventWriter(long) in JVMCI > > test/jdk/jdk/jfr/jvm/TestGetEventWriter.java line 102: > >> 100: } >> 101: >> 102: private static ResolvedJavaMethod findCommitMethod(MetaAccessProvider metaAccess, Class eventClass) { > > Can you please move all the JVMCI support stuff to the end of the file instead of the beginning? Only because it makes for easier reading for the non-JVMCI cases, thanks. Will do. ------------- PR: https://git.openjdk.org/jdk/pull/9449 From dnsimon at openjdk.org Mon Aug 22 15:05:33 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 22 Aug 2022 15:05:33 GMT Subject: RFR: 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter [v2] In-Reply-To: References: Message-ID: <97pUUG24fHjOj6xxu7Er9LrBvwgXFmoof6rz2vM2eDs=.0c8abea6-6cd2-4030-ada2-7c5ffb5142d5@github.com> On Mon, 22 Aug 2022 13:54:43 GMT, Markus Gr?nlund wrote: >> test/jdk/jdk/jfr/jvm/TestGetEventWriter.java line 60: >> >>> 58: * @run main/othervm jdk.jfr.jvm.TestGetEventWriter >>> 59: * >>> 60: * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -Dtest.jvmci=true --add-exports=jdk.jfr/jdk.jfr.internal.event=ALL-UNNAMED >> >> I think `--add-exports=jdk.jfr/jdk.jfr.internal.event=ALL-UNNAMED` should be added to all `@run` specs in this test. See more details [here](https://github.com/openjdk/jdk/pull/8383#discussion_r915755771). > > We export certain modules and packages dynamically to the caller module when it registers an event. So don't think it is needed for those. Maybe I'm missing the point of these tests but I assume they are trying to exercise the blessed method checks in which case the IllegalAccessError message should be coming from here: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/instrumentation/jfrResolution.cpp#L81 Instead, it is coming from the module access checks. Please see more details at https://github.com/openjdk/jdk/pull/8383#discussion_r915755771 ------------- PR: https://git.openjdk.org/jdk/pull/9449 From dnsimon at openjdk.org Mon Aug 22 15:12:24 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 22 Aug 2022 15:12:24 GMT Subject: RFR: 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter [v3] In-Reply-To: References: Message-ID: > [JDK-8282420](https://bugs.openjdk.org/browse/JDK-8282420) introduced the notion of "blessed methods" which are those that can link against `jdk.jfr.internal.event.EventWriterFactory.getEventWriter(long)`. > This PR enhances the JVMCI ConstantPool API so that it can take a caller context when resolving a method to enforce this constraint properly. Doug Simon 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 remote-tracking branch 'openjdk-jdk/master' into JDK-8290075 - moved JVMCI code to end of file - support special linkage rules for jdk.jfr.internal.event.EventWriterFactory.getEventWriter(long) in JVMCI ------------- Changes: https://git.openjdk.org/jdk/pull/9449/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9449&range=02 Stats: 146 lines in 12 files changed: 127 ins; 6 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/9449.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9449/head:pull/9449 PR: https://git.openjdk.org/jdk/pull/9449 From mdoerr at openjdk.org Mon Aug 22 15:26:41 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 22 Aug 2022 15:26:41 GMT Subject: RFR: 8290025: Remove the Sweeper [v11] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 10:45:20 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund 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 'master' into 8290025_remove_sweeper > - Trigger GC from adapter blob allocations > - Zhengyu comments v1 > - Redundant variable > - Polish comment > - Merge branch 'master' into 8290025_remove_sweeper > - Removed more stale things > - Remove incorrect comment > - Feedback v2 > - Feedback v1 > - ... and 1 more: https://git.openjdk.org/jdk/compare/0c40128f...a06919b1 Can you please add a null check? C1 patching stubs contain null Oops on PPC64. --- a/src/hotspot/share/gc/shared/barrierSetNMethod.cpp +++ b/src/hotspot/share/gc/shared/barrierSetNMethod.cpp @@ -72,7 +72,9 @@ bool BarrierSetNMethod::nmethod_entry_barrier(nmethod* nm) { // conversion that performs the load barriers. This is too subtle, so we instead // perform an explicit keep alive call. oop obj = NativeAccess::oop_load(p); - Universe::heap()->keep_alive(obj); + if (obj != nullptr) { + Universe::heap()->keep_alive(obj); + } } virtual void do_oop(narrowOop* p) { ShouldNotReachHere(); } ------------- Changes requested by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/9741 From stuefe at openjdk.org Mon Aug 22 15:33:21 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 22 Aug 2022 15:33:21 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 10:53:27 GMT, Johan Sj?l?n wrote: > This PR removes a lot of boilerplate that was required when creating multi-threaded tests and ports 2 tests to show that the number of lines of code is significantly reduced and that porting is fairly trivial. The ported tests also serve as an introduction to others who're looking into writing their own multi-threaded tests. > > Testing: Ran the ported tests on my machine, also running the tests on x64 {Windows, Linux, Mac OS X], aarch64 { Linux, Mac OS X} and tier1 for "completeness". I have tried to understand for the last half hour the interworkings of the State, the Stategenerator, and what the lambda arguments to TTG try to be. For the latter, I only see two cases: `[]() { return 0; }` and `[&]() { return &test; }`. So what purpose does have the state generator, if all we use it for is just generating constants? I worry that many of these improvements just increase the cognitive load, especially for the casual developer that does test fixes and backports, without bringing many benefits to the table. test/hotspot/gtest/threadHelper.inline.hpp line 148: > 146: }; > 147: > 148: // A TestThreadGroup tracks multiple threads running the same function. So we have F, which is kind of clear, S, which is a state?, and then also a state generator? Which apparently needs to define operator () and return a state? Could you please document what the template parameters are and what is expected of them? Does N really need to be a template parameter? You lose flexibility, and it is less readable too. ------------- PR: https://git.openjdk.org/jdk/pull/9962 From stuefe at openjdk.org Mon Aug 22 15:41:38 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 22 Aug 2022 15:41:38 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 10:53:27 GMT, Johan Sj?l?n wrote: > This PR removes a lot of boilerplate that was required when creating multi-threaded tests and ports 2 tests to show that the number of lines of code is significantly reduced and that porting is fairly trivial. The ported tests also serve as an introduction to others who're looking into writing their own multi-threaded tests. > > Testing: Ran the ported tests on my machine, also running the tests on x64 {Windows, Linux, Mac OS X], aarch64 { Linux, Mac OS X} and tier1 for "completeness". p.s. sorry for sounding grumpy, that was not my intention. The reduction in LOC is certainly nice. I just would like it if a look at an API would make it clear to me how it is to be used. In this case, e.g., what purpose state and state generator have and what methods they should implement. Thank you. ------------- PR: https://git.openjdk.org/jdk/pull/9962 From stuefe at openjdk.org Mon Aug 22 15:45:25 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 22 Aug 2022 15:45:25 GMT Subject: RFR: JDK-8292351: tty should always live [v6] In-Reply-To: References: Message-ID: > The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. > > This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. > > tty should always be safe to write to, and that is trivial to do. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Last changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9874/files - new: https://git.openjdk.org/jdk/pull/9874/files/9d6a9082..5c1f4caf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9874&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9874&range=04-05 Stats: 7 lines in 1 file changed: 3 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9874/head:pull/9874 PR: https://git.openjdk.org/jdk/pull/9874 From mgronlun at openjdk.org Mon Aug 22 16:00:46 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 22 Aug 2022 16:00:46 GMT Subject: RFR: 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter [v3] In-Reply-To: <97pUUG24fHjOj6xxu7Er9LrBvwgXFmoof6rz2vM2eDs=.0c8abea6-6cd2-4030-ada2-7c5ffb5142d5@github.com> References: <97pUUG24fHjOj6xxu7Er9LrBvwgXFmoof6rz2vM2eDs=.0c8abea6-6cd2-4030-ada2-7c5ffb5142d5@github.com> Message-ID: On Mon, 22 Aug 2022 15:01:19 GMT, Doug Simon wrote: >> We export certain modules and packages dynamically to the caller module when it registers an event. So don't think it is needed for those. > > Maybe I'm missing the point of these tests but I assume they are trying to exercise the blessed method checks in which case the IllegalAccessError message should be coming from here: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/instrumentation/jfrResolution.cpp#L81 > Instead, it is coming from the module access checks. > Please see more details at https://github.com/openjdk/jdk/pull/8383#discussion_r915755771 Now I understand better what you are referring to, thanks for noticing this. I think your suggestion is good, it makes sense to make the tests better targeted. Please also add the --add-exports to the other tests as well. Thanks again for seeing this. ------------- PR: https://git.openjdk.org/jdk/pull/9449 From eosterlund at openjdk.org Mon Aug 22 16:06:48 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 22 Aug 2022 16:06:48 GMT Subject: RFR: 8290025: Remove the Sweeper [v11] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 10:45:20 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund 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 'master' into 8290025_remove_sweeper > - Trigger GC from adapter blob allocations > - Zhengyu comments v1 > - Redundant variable > - Polish comment > - Merge branch 'master' into 8290025_remove_sweeper > - Removed more stale things > - Remove incorrect comment > - Feedback v2 > - Feedback v1 > - ... and 1 more: https://git.openjdk.org/jdk/compare/0c40128f...a06919b1 > Can you please add a null check? C1 patching stubs contain null Oops on PPC64. > > ```diff > --- a/src/hotspot/share/gc/shared/barrierSetNMethod.cpp > +++ b/src/hotspot/share/gc/shared/barrierSetNMethod.cpp > @@ -72,7 +72,9 @@ bool BarrierSetNMethod::nmethod_entry_barrier(nmethod* nm) { > // conversion that performs the load barriers. This is too subtle, so we instead > // perform an explicit keep alive call. > oop obj = NativeAccess::oop_load(p); > - Universe::heap()->keep_alive(obj); > + if (obj != nullptr) { > + Universe::heap()->keep_alive(obj); > + } > } > > virtual void do_oop(narrowOop* p) { ShouldNotReachHere(); } > ``` > > Or should we fix that separately? Seems to be related to [JDK-8292077](https://bugs.openjdk.org/browse/JDK-8292077). Ah. Good find. I can add the null check. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From egahlin at openjdk.org Mon Aug 22 16:35:32 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 22 Aug 2022 16:35:32 GMT Subject: RFR: 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter [v3] In-Reply-To: References: <97pUUG24fHjOj6xxu7Er9LrBvwgXFmoof6rz2vM2eDs=.0c8abea6-6cd2-4030-ada2-7c5ffb5142d5@github.com> Message-ID: On Mon, 22 Aug 2022 15:55:36 GMT, Markus Gr?nlund wrote: >> Maybe I'm missing the point of these tests but I assume they are trying to exercise the blessed method checks in which case the IllegalAccessError message should be coming from here: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/instrumentation/jfrResolution.cpp#L81 >> Instead, it is coming from the module access checks. >> Please see more details at https://github.com/openjdk/jdk/pull/8383#discussion_r915755771 > > Now I understand better what you are referring to, thanks for noticing this. I think your suggestion is good, it makes sense to make the tests better targeted. Please also add the --add-exports to the other tests as well. Thanks again for seeing this. I think we want to test what is being shipped. From the beginning there was --add-exports, but then it was removed and we found issues (unexpected exception). Maybe we can have both, but I think it would be unfortunate to not test the "full scenario" (which might include registering an event). ------------- PR: https://git.openjdk.org/jdk/pull/9449 From cstein at openjdk.org Mon Aug 22 16:39:17 2022 From: cstein at openjdk.org (Christian Stein) Date: Mon, 22 Aug 2022 16:39:17 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v2] In-Reply-To: References: Message-ID: <8gFr6V8k4vF-3cJt34Vp_6F-MtOb2TyMwJNjhgUveoU=.535be13e-459c-4cd3-8bca-5eb66587a084@github.com> > Please review the change to update to using jtreg 7. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Revert junit.java Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Update to new JUnit JAR file With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2"). This change updates the hard-coded library tag value to the new JUnit JAR file. Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316, in order to unblock the "Update to use jtreg 7" PR 9393: https://github.com/openjdk/jdk/pull/9393 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Update github-actions.conf - JDK-8289798: Update to use jtreg 7 ------------- Changes: https://git.openjdk.org/jdk/pull/9393/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=01 Stats: 10 lines in 7 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/9393.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393 PR: https://git.openjdk.org/jdk/pull/9393 From dnsimon at openjdk.org Mon Aug 22 16:52:32 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 22 Aug 2022 16:52:32 GMT Subject: RFR: 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter [v3] In-Reply-To: References: <97pUUG24fHjOj6xxu7Er9LrBvwgXFmoof6rz2vM2eDs=.0c8abea6-6cd2-4030-ada2-7c5ffb5142d5@github.com> Message-ID: On Mon, 22 Aug 2022 16:29:24 GMT, Erik Gahlin wrote: >> Now I understand better what you are referring to, thanks for noticing this. I think your suggestion is good, it makes sense to make the tests better targeted. Please also add the --add-exports to the other tests as well. Thanks again for seeing this. > > I think we want to test what is being shipped. From the beginning there was --add-exports, but then it was removed and we found issues (unexpected exception). Maybe we can have both, but I think it would be unfortunate to not test the "full scenario" (which might include registering an event). As far as I can see, without the `--add-exports`, all that is being tested is module access checks. Are there other tests specifically testing the access checks in [`JfrResolution::on_runtime_resolution`](https://github.com/openjdk/jdk/blob/aa9b8f04bf74d5fa00f2b27895e7369abea3a930/src/hotspot/share/jfr/instrumentation/jfrResolution.cpp#L55). That said, I'm happy to leave the original tests in `TestGetEventWriter.java` as is. ------------- PR: https://git.openjdk.org/jdk/pull/9449 From mdoerr at openjdk.org Mon Aug 22 17:05:42 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 22 Aug 2022 17:05:42 GMT Subject: RFR: 8290025: Remove the Sweeper [v11] In-Reply-To: References: Message-ID: <1j1txO3hXoT_cHgABrvgYMw-0JRWoCXdaKZT0SoRCZQ=.045f1b00-b034-4898-a071-619db61b6364@github.com> On Mon, 22 Aug 2022 16:04:18 GMT, Erik ?sterlund wrote: > > Can you please add a null check? C1 patching stubs contain null Oops on PPC64. > > ```diff > > --- a/src/hotspot/share/gc/shared/barrierSetNMethod.cpp > > +++ b/src/hotspot/share/gc/shared/barrierSetNMethod.cpp > > @@ -72,7 +72,9 @@ bool BarrierSetNMethod::nmethod_entry_barrier(nmethod* nm) { > > // conversion that performs the load barriers. This is too subtle, so we instead > > // perform an explicit keep alive call. > > oop obj = NativeAccess::oop_load(p); > > - Universe::heap()->keep_alive(obj); > > + if (obj != nullptr) { > > + Universe::heap()->keep_alive(obj); > > + } > > } > > > > virtual void do_oop(narrowOop* p) { ShouldNotReachHere(); } > > ``` > > > > > > > > > > > > > > > > > > > > > > > > Or should we fix that separately? Seems to be related to [JDK-8292077](https://bugs.openjdk.org/browse/JDK-8292077). > > Ah. Good find. I can add the null check. I just noticed that there is already a bug open: https://bugs.openjdk.org/browse/JDK-8292368 I think I should better fix it separately in case it will be needed by backports. Thanks for taking a look! ------------- PR: https://git.openjdk.org/jdk/pull/9741 From duke at openjdk.org Mon Aug 22 17:09:34 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 22 Aug 2022 17:09:34 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 14:41:29 GMT, Thomas Stuefe wrote: >So we have F, which is kind of clear, S, which is a state?, and then also a state generator? Which apparently needs to define operator () and return a state? >Could you please document what the template parameters are and what is expected of them? Absolutely. I'll also lengthen their name, to make them more clear- >Does N really need to be a template parameter? You lose flexibility, and it is less readable too. What flexibility are we losing? We're not going to be dynamically reallocate the amount of threads in a `TestThreadGroup`, or is this the exact use case you're imagining in the future? I don't think it's necessarily less readable. It's fairly standard in C++ STL to use template arguments for sizes (see `std::array`). I know we typically use raw pointers and length variables in Hotspot, so it's certainly unidiomatic from those eyes. To me, it's more readable, because it's a hint to me that "aha, this size won't change during execution". ------------- PR: https://git.openjdk.org/jdk/pull/9962 From vlivanov at openjdk.org Mon Aug 22 17:13:51 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 22 Aug 2022 17:13:51 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v6] In-Reply-To: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: > (PR depends on #9923.) > > Constants which reside outside code cache are not guaranteed to be reachable in > RIP-relative addressing mode from stub code, but absolute addressing mode requires a > scratch register. > > Provide a scratch register to ensure constants are reachable irrespective of > process memory layout. > > Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. > > Testing: > - [x] hs-tier1 - hs-tier4 > - [x] x86_32 hotspot build Vladimir Ivanov has updated the pull request incrementally with three additional commits since the last revision: - formatting - Merge branch 'trig_rscratch' of https://github.com/iwanowww/jdk into trig_rscratch - x86_32 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9932/files - new: https://git.openjdk.org/jdk/pull/9932/files/8a16894a..6ea69dd2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=04-05 Stats: 116 lines in 3 files changed: 7 ins; 88 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/9932.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9932/head:pull/9932 PR: https://git.openjdk.org/jdk/pull/9932 From vlivanov at openjdk.org Mon Aug 22 17:11:45 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 22 Aug 2022 17:11:45 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v5] In-Reply-To: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: > (PR depends on #9923.) > > Constants which reside outside code cache are not guaranteed to be reachable in > RIP-relative addressing mode from stub code, but absolute addressing mode requires a > scratch register. > > Provide a scratch register to ensure constants are reachable irrespective of > process memory layout. > > Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. > > Testing: > - [x] hs-tier1 - hs-tier4 > - [x] x86_32 hotspot build Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/cpu/x86/assembler_x86.cpp Co-authored-by: Aleksey Shipil?v ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9932/files - new: https://git.openjdk.org/jdk/pull/9932/files/911e8c1c..8a16894a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9932.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9932/head:pull/9932 PR: https://git.openjdk.org/jdk/pull/9932 From mdoerr at openjdk.org Mon Aug 22 17:27:44 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 22 Aug 2022 17:27:44 GMT Subject: RFR: 8290025: Remove the Sweeper [v11] In-Reply-To: References: Message-ID: <2_gvhEp6LeTpcw9e-pa-r3vAbNGe5WhxsnakKQpqhfo=.0ee757ff-12ff-40f3-ae75-5410fc2505f8@github.com> On Fri, 12 Aug 2022 10:45:20 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund 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 'master' into 8290025_remove_sweeper > - Trigger GC from adapter blob allocations > - Zhengyu comments v1 > - Redundant variable > - Polish comment > - Merge branch 'master' into 8290025_remove_sweeper > - Removed more stale things > - Remove incorrect comment > - Feedback v2 > - Feedback v1 > - ... and 1 more: https://git.openjdk.org/jdk/compare/0c40128f...a06919b1 Created https://github.com/openjdk/jdk/pull/9968 for the missing null check. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From mgronlun at openjdk.org Mon Aug 22 17:29:35 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 22 Aug 2022 17:29:35 GMT Subject: RFR: 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter [v3] In-Reply-To: References: <97pUUG24fHjOj6xxu7Er9LrBvwgXFmoof6rz2vM2eDs=.0c8abea6-6cd2-4030-ada2-7c5ffb5142d5@github.com> Message-ID: On Mon, 22 Aug 2022 16:48:53 GMT, Doug Simon wrote: >> I think we want to test what is being shipped. From the beginning there was --add-exports, but then it was removed and we found issues (unexpected exception). Maybe we can have both, but I think it would be unfortunate to not test the "full scenario" (which might include registering an event). > > As far as I can see, without the `--add-exports`, all that is being tested is module access checks. Are there other tests specifically testing the access checks in [`JfrResolution::on_runtime_resolution`](https://github.com/openjdk/jdk/blob/aa9b8f04bf74d5fa00f2b27895e7369abea3a930/src/hotspot/share/jfr/instrumentation/jfrResolution.cpp#L55). > That said, I'm happy to leave the original tests in `TestGetEventWriter.java` as is. Ok Douglas, please leave the original tests as is. There are a few paths involved, and we need to remember why we ended up stating the tests as we did. We can revisit this later, so let's not block you from getting this in. ------------- PR: https://git.openjdk.org/jdk/pull/9449 From mdoerr at openjdk.org Mon Aug 22 17:34:15 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 22 Aug 2022 17:34:15 GMT Subject: RFR: 8292368: [ppc64] internal error g1BarrierSet.inline.hpp assert(oopDesc::is_oop(pre_val, true)) failed: Error Message-ID: C1 patching stubs contain null Oops on PPC64. Null check is missing in [JDK-8292077](https://bugs.openjdk.org/browse/JDK-8292077). ------------- Commit messages: - 8292368: [ppc64] internal error g1BarrierSet.inline.hpp assert(oopDesc::is_oop(pre_val, true)) failed: Error Changes: https://git.openjdk.org/jdk/pull/9968/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9968&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292368 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9968.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9968/head:pull/9968 PR: https://git.openjdk.org/jdk/pull/9968 From eosterlund at openjdk.org Mon Aug 22 17:34:17 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 22 Aug 2022 17:34:17 GMT Subject: RFR: 8292368: [ppc64] internal error g1BarrierSet.inline.hpp assert(oopDesc::is_oop(pre_val, true)) failed: Error In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 17:23:47 GMT, Martin Doerr wrote: > C1 patching stubs contain null Oops on PPC64. Null check is missing in [JDK-8292077](https://bugs.openjdk.org/browse/JDK-8292077). Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/9968 From shade at openjdk.org Mon Aug 22 17:42:10 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 22 Aug 2022 17:42:10 GMT Subject: RFR: 8292368: [ppc64] internal error g1BarrierSet.inline.hpp assert(oopDesc::is_oop(pre_val, true)) failed: Error In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 17:23:47 GMT, Martin Doerr wrote: > C1 patching stubs contain null Oops on PPC64. Null check is missing in [JDK-8292077](https://bugs.openjdk.org/browse/JDK-8292077). Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9968 From dnsimon at openjdk.org Mon Aug 22 18:15:49 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 22 Aug 2022 18:15:49 GMT Subject: RFR: 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter [v4] In-Reply-To: References: Message-ID: > [JDK-8282420](https://bugs.openjdk.org/browse/JDK-8282420) introduced the notion of "blessed methods" which are those that can link against `jdk.jfr.internal.event.EventWriterFactory.getEventWriter(long)`. > This PR enhances the JVMCI ConstantPool API so that it can take a caller context when resolving a method to enforce this constraint properly. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: fix JVMCI specific test failure in TestGetEventWriter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9449/files - new: https://git.openjdk.org/jdk/pull/9449/files/88f1288e..efa9e0eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9449&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9449&range=02-03 Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9449.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9449/head:pull/9449 PR: https://git.openjdk.org/jdk/pull/9449 From mdoerr at openjdk.org Mon Aug 22 18:28:27 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 22 Aug 2022 18:28:27 GMT Subject: RFR: 8292368: [ppc64] internal error g1BarrierSet.inline.hpp assert(oopDesc::is_oop(pre_val, true)) failed: Error In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 17:23:47 GMT, Martin Doerr wrote: > C1 patching stubs contain null Oops on PPC64. Null check is missing in [JDK-8292077](https://bugs.openjdk.org/browse/JDK-8292077). Thanks for the reviews! ------------- PR: https://git.openjdk.org/jdk/pull/9968 From iklam at openjdk.org Mon Aug 22 18:42:35 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 22 Aug 2022 18:42:35 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v7] In-Reply-To: References: Message-ID: > Current in gdb, you can print information about a class or method with something like > > > call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) > call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) > > > However, it's difficult to find a class or method by its name and print out its contents. > > This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. > > - `findclass()`: class name only > - `findmethod()`: class name and method name > - `findmethod2()`: class name and method name/signature > > I also cleaned up `BytecodeTracer` to remove unnecessary complexity. > > Here are some examples: > > > (gdb) call findclass("java/lang/Object", 0) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > > (gdb) call findclass("java/lang/Object", 1) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000658 : ()V > 0x00007fffb40010f0 finalize : ()V > 0x00007fffb4000f00 wait0 : (J)V > 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z > 0x00007fffb4000aa0 toString : ()Ljava/lang/String; > 0x00007fffb40007f0 hashCode : ()I > 0x00007fffb4000720 getClass : ()Ljava/lang/Class; > 0x00007fffb40009a0 clone : ()Ljava/lang/Object; > 0x00007fffb4000b50 notify : ()V > 0x00007fffb4000c20 notifyAll : ()V > 0x00007fffb4000e50 wait : (J)V > 0x00007fffb4001028 wait : (JI)V > 0x00007fffb4000d08 wait : ()V > > (gdb) call findclass("*ClassLoader", 0) > [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [....] > > (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000d08 wait : ()V > 0x00007fffb4000ce8 0 fast_aload_0 > 0x00007fffb4000ce9 1 lconst_0 > 0x00007fffb4000cea 2 invokevirtual 38 > 0x00007fffb4000ced 5 return Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Use proper locking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9957/files - new: https://git.openjdk.org/jdk/pull/9957/files/6c529f8d..57ce8604 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=05-06 Stats: 27 lines in 3 files changed: 3 ins; 4 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/9957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9957/head:pull/9957 PR: https://git.openjdk.org/jdk/pull/9957 From hseigel at openjdk.org Mon Aug 22 18:46:38 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 22 Aug 2022 18:46:38 GMT Subject: RFR: 8292596: Make SymbolHashMap a ResourceHashtable [v4] In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 16:00:36 GMT, Coleen Phillimore wrote: >> Please review this straightforward change to use ResourceHashtable for SymbolHashMap, which is used by the Class File Reconstituter. The table maps Symbol* to constant pool indices for loaded classes (Symbol refcounting unnecessary as the class is not unloaded because it's in use). >> Tested with jvmti tests locally and tier 1-3. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Hide SymbolHash inside of ConstantPool so people don't get the wrong idea about it. Still looks good! Thanks, Harold ------------- PR: https://git.openjdk.org/jdk/pull/9917 From coleenp at openjdk.org Mon Aug 22 18:46:39 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 22 Aug 2022 18:46:39 GMT Subject: RFR: 8292596: Make SymbolHashMap a ResourceHashtable [v4] In-Reply-To: References: Message-ID: <5a3QBLJCbbf4SxdON2-HfugPgwHDeg7QetA_pVR1Rh4=.e404a54e-e3bd-43ba-874a-7a1d46f41397@github.com> On Fri, 19 Aug 2022 16:00:36 GMT, Coleen Phillimore wrote: >> Please review this straightforward change to use ResourceHashtable for SymbolHashMap, which is used by the Class File Reconstituter. The table maps Symbol* to constant pool indices for loaded classes (Symbol refcounting unnecessary as the class is not unloaded because it's in use). >> Tested with jvmti tests locally and tier 1-3. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Hide SymbolHash inside of ConstantPool so people don't get the wrong idea about it. Thanks Harold and David! ------------- PR: https://git.openjdk.org/jdk/pull/9917 From coleenp at openjdk.org Mon Aug 22 18:46:40 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 22 Aug 2022 18:46:40 GMT Subject: Integrated: 8292596: Make SymbolHashMap a ResourceHashtable In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 11:41:14 GMT, Coleen Phillimore wrote: > Please review this straightforward change to use ResourceHashtable for SymbolHashMap, which is used by the Class File Reconstituter. The table maps Symbol* to constant pool indices for loaded classes (Symbol refcounting unnecessary as the class is not unloaded because it's in use). > Tested with jvmti tests locally and tier 1-3. This pull request has now been integrated. Changeset: 8e8ee4b6 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/8e8ee4b6f22657a7efba8d7998f3c309f334a086 Stats: 172 lines in 4 files changed: 16 ins; 142 del; 14 mod 8292596: Make SymbolHashMap a ResourceHashtable Reviewed-by: hseigel, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/9917 From iklam at openjdk.org Mon Aug 22 18:54:31 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 22 Aug 2022 18:54:31 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v5] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 05:29:01 GMT, Thomas Stuefe wrote: > Hi Ioi, > > this looks neat. Not a full review, just some remarks: > > * Not your patch, but while playing with this I found that "call help()" needs a RM, which means gdb crashes out in a non-attached thread (e.g. the primordial one). Would be nice if no RM were needed. I think that would be too hard to do, as a lot of the printing functions depend on RM. > * Calling "findclass" from a java thread yielded this: > > ``` > (gdb) call findclass("*", 7) > [Thread 0x7fffb28cf700 (LWP 112211) exited] > > "Executing findclass" > > Thread 2 "java" received signal SIGSEGV, Segmentation fault. > 0x00007ffff6fe17ba in assert_locked_or_safepoint (lock=0x7ffff0027320) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/runtime/mutexLocker.cpp:178 > 178 fatal("must own lock %s", lock->name()); > ... > (gdb) bt > #0 0x00007ffff6fe17ba in assert_locked_or_safepoint (lock=0x7ffff0027320) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/runtime/mutexLocker.cpp:178 > #1 assert_locked_or_safepoint (lock=0x7ffff0027320) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/runtime/mutexLocker.cpp:172 > #2 0x00007ffff639dcfb in ClassLoaderDataGraphIteratorBase::ClassLoaderDataGraphIteratorBase (this=0x7ffff57b3390) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/runtime/handles.hpp:263 > #3 ClassLoaderDataGraph::classes_do (klass_closure=klass_closure at entry=0x7ffff57b3420) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/classLoaderDataGraph.cpp:366 > #4 0x00007ffff63acbe0 in ClassPrinter::print_classes_unlocked (class_name_pattern=class_name_pattern at entry=0x7ffff7d5de80 "*", flags=flags at entry=7) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/classPrinter.cpp:139 > ``` I changed ClassPrinter to use proper locking. The down side is if you call it in some narrow windows where the locks are already held, gdb would deadlock, but I think those windows are very small. > * You could add a simple test at least as gtests, looking for some well-known classes. I'll work on a few gtest cases. > * instead of using int for flags, maybe use an enum class and define the bitwise combine operator? Like this: > > ``` > enum class Mode : int { > PRINT_METHOD_NAME = 1 << 0, > PRINT_BYTECODE = 1 << 1, > PRINT_BYTECODE_ADDR = 1 << 2, > PRINT_DYNAMIC = 1 << 3, // extra information for invokedynamic (and dynamic constant ...) > }; > > constexpr enum Mode operator | (enum Mode selfValue, enum Mode inValue) { return (Mode)(uint32_t(selfValue) | uint32_t(inValue)); } > ``` The problem with 'enum class' is you can't use it easily inside gdb. You must do a lot of typing like: call findclass("*Object", ClassPrinter::Mode::PRINT_ALL) call findclass("*Object", ClassPrinter::Mode::PRINT_METHOD_NAME | ClassPrinter::Mode::PRINT_METHOD_ADDR) In contrast, it's much easier to do this to enable everything. call findclass("*Object", 0xff) ------------- PR: https://git.openjdk.org/jdk/pull/9957 From iklam at openjdk.org Mon Aug 22 18:59:30 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 22 Aug 2022 18:59:30 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v5] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 05:01:22 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> also print Method pointer > > src/hotspot/share/classfile/classPrinter.hpp line 59: > >> 57: }; >> 58: >> 59: // flags must be OR'ed from ClassPrinter::Mode for the next 3 functions > > Can you give us a mode PRINT_ALL that or'es all of them modes together, and make that maybe the default for flags? gdb doesn't support default parameters (I think the info for default params is not available in the debug info), so you need to pass in `flags` explicitly. If you pass 0 for `findclass`, it prints only the class names. If you pass 0 for `findmethod` and `findmethods`, they print only the class names and method names. Printing everything by default may be too overwhelming. BTW, I think `findmethod` vs `findmethods` may not be the right names. The former takes only method name, while the latter also takes a signature. Maybe I should rename the latter to `findmethodex`? ------------- PR: https://git.openjdk.org/jdk/pull/9957 From vlivanov at openjdk.org Mon Aug 22 19:42:38 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 22 Aug 2022 19:42:38 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v4] In-Reply-To: References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: On Mon, 22 Aug 2022 12:41:32 GMT, Aleksey Shipilev wrote: > x86_32 tier1 is good. Here is the patch that does the symmetric changes in stubGenerator_x86_64.cpp Thank you. Incorporated. ------------- PR: https://git.openjdk.org/jdk/pull/9932 From coleenp at openjdk.org Mon Aug 22 19:51:48 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 22 Aug 2022 19:51:48 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v7] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 18:42:35 GMT, Ioi Lam wrote: >> Current in gdb, you can print information about a class or method with something like >> >> >> call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) >> call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) >> >> >> However, it's difficult to find a class or method by its name and print out its contents. >> >> This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. >> >> - `findclass()`: class name only >> - `findmethod()`: class name and method name >> - `findmethod2()`: class name and method name/signature >> >> I also cleaned up `BytecodeTracer` to remove unnecessary complexity. >> >> Here are some examples: >> >> >> (gdb) call findclass("java/lang/Object", 0) >> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' >> >> (gdb) call findclass("java/lang/Object", 1) >> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' >> 0x00007fffb4000658 : ()V >> 0x00007fffb40010f0 finalize : ()V >> 0x00007fffb4000f00 wait0 : (J)V >> 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z >> 0x00007fffb4000aa0 toString : ()Ljava/lang/String; >> 0x00007fffb40007f0 hashCode : ()I >> 0x00007fffb4000720 getClass : ()Ljava/lang/Class; >> 0x00007fffb40009a0 clone : ()Ljava/lang/Object; >> 0x00007fffb4000b50 notify : ()V >> 0x00007fffb4000c20 notifyAll : ()V >> 0x00007fffb4000e50 wait : (J)V >> 0x00007fffb4001028 wait : (JI)V >> 0x00007fffb4000d08 wait : ()V >> >> (gdb) call findclass("*ClassLoader", 0) >> [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' >> [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' >> [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' >> [....] >> >> (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) >> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' >> 0x00007fffb4000d08 wait : ()V >> 0x00007fffb4000ce8 0 fast_aload_0 >> 0x00007fffb4000ce9 1 lconst_0 >> 0x00007fffb4000cea 2 invokevirtual 38 >> 0x00007fffb4000ced 5 return > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Use proper locking I'm still trying to understand the need for new code for this but I have a couple of initial comments. src/hotspot/share/interpreter/bytecodeTracer.cpp line 434: > 432: // TODO: print info for tag.is_dynamic_constant() > 433: } > 434: } This should be a function in ConstantPool::print() src/hotspot/share/interpreter/bytecodeTracer.cpp line 462: > 460: } > 461: } > 462: } Line 444-461 should call a function in cpCache like: void ConstantPoolCacheEntry::print(outputStream* st, int index) const { If this doesn't have the format you want, you can enhance this function. ------------- PR: https://git.openjdk.org/jdk/pull/9957 From coleenp at openjdk.org Mon Aug 22 20:09:05 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 22 Aug 2022 20:09:05 GMT Subject: RFR: 8292743: Missing include resourceHash.hpp Message-ID: I was missing this include in the last checkin. Tier1 on 4 platforms in progress (along with GHA which I don't know why they didn't fail with my last checkin) ------------- Commit messages: - 8292743: Missing include resourceHash.hpp Changes: https://git.openjdk.org/jdk/pull/9969/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9969&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292743 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9969.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9969/head:pull/9969 PR: https://git.openjdk.org/jdk/pull/9969 From dcubed at openjdk.org Mon Aug 22 20:21:29 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 22 Aug 2022 20:21:29 GMT Subject: RFR: 8292743: Missing include resourceHash.hpp In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 20:00:23 GMT, Coleen Phillimore wrote: > I was missing this include in the last checkin. Tier1 on 4 platforms in progress (along with GHA which I don't know why they didn't fail with my last checkin) Thumbs up. This is a trivial change. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/9969 From stefank at openjdk.org Mon Aug 22 20:21:29 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 22 Aug 2022 20:21:29 GMT Subject: RFR: 8292743: Missing include resourceHash.hpp In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 20:00:23 GMT, Coleen Phillimore wrote: > I was missing this include in the last checkin. Tier1 on 4 platforms in progress (along with GHA which I don't know why they didn't fail with my last checkin) Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9969 From duke at openjdk.org Mon Aug 22 20:24:08 2022 From: duke at openjdk.org (Cesar Soares) Date: Mon, 22 Aug 2022 20:24:08 GMT Subject: RFR: 8292743: Missing include resourceHash.hpp In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 20:00:23 GMT, Coleen Phillimore wrote: > I was missing this include in the last checkin. Tier1 on 4 platforms in progress (along with GHA which I don't know why they didn't fail with my last checkin) LGTM :-) ------------- PR: https://git.openjdk.org/jdk/pull/9969 From vlivanov at openjdk.org Mon Aug 22 20:31:27 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 22 Aug 2022 20:31:27 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v7] In-Reply-To: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: > (PR depends on #9923.) > > Constants which reside outside code cache are not guaranteed to be reachable in > RIP-relative addressing mode from stub code, but absolute addressing mode requires a > scratch register. > > Provide a scratch register to ensure constants are reachable irrespective of > process memory layout. > > Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. > > Testing: > - [x] hs-tier1 - hs-tier4 > - [x] x86_32 hotspot build Vladimir Ivanov has updated the pull request incrementally with two additional commits since the last revision: - reuse is_always_reachable - is_reachable_from ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9932/files - new: https://git.openjdk.org/jdk/pull/9932/files/6ea69dd2..9b4e941d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=05-06 Stats: 119 lines in 1 file changed: 49 ins; 58 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9932.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9932/head:pull/9932 PR: https://git.openjdk.org/jdk/pull/9932 From clanger at openjdk.org Mon Aug 22 20:31:49 2022 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 22 Aug 2022 20:31:49 GMT Subject: RFR: JDK-8292351: tty should always live [v6] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 15:45:25 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Last changes Marked as reviewed by clanger (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9874 From coleenp at openjdk.org Mon Aug 22 20:34:59 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 22 Aug 2022 20:34:59 GMT Subject: RFR: 8292743: Missing include resourceHash.hpp In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 20:00:23 GMT, Coleen Phillimore wrote: > I was missing this include in the last checkin. Tier1 on 4 platforms in progress (along with GHA which I don't know why they didn't fail with my last checkin) Thanks for the quick reviews, Dan and Stefan. ------------- PR: https://git.openjdk.org/jdk/pull/9969 From coleenp at openjdk.org Mon Aug 22 20:34:59 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 22 Aug 2022 20:34:59 GMT Subject: Integrated: 8292743: Missing include resourceHash.hpp In-Reply-To: References: Message-ID: <5V6oXi2ilTc6iUfABoovrEKN5PUqWDvcjb6Du1z6USA=.f5e3d6ed-faaa-42fc-9f8a-47c23e6421e9@github.com> On Mon, 22 Aug 2022 20:00:23 GMT, Coleen Phillimore wrote: > I was missing this include in the last checkin. Tier1 on 4 platforms in progress (along with GHA which I don't know why they didn't fail with my last checkin) This pull request has now been integrated. Changeset: 27af0144 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/27af0144ea57e86d9b81c2b328fad66e4a046f61 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8292743: Missing include resourceHash.hpp Reviewed-by: dcubed, stefank ------------- PR: https://git.openjdk.org/jdk/pull/9969 From vlivanov at openjdk.org Mon Aug 22 20:44:28 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 22 Aug 2022 20:44:28 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v8] In-Reply-To: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: > (PR depends on #9923.) > > Constants which reside outside code cache are not guaranteed to be reachable in > RIP-relative addressing mode from stub code, but absolute addressing mode requires a > scratch register. > > Provide a scratch register to ensure constants are reachable irrespective of > process memory layout. > > Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. > > Testing: > - [x] hs-tier1 - hs-tier4 > - [x] x86_32 hotspot build Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9932/files - new: https://git.openjdk.org/jdk/pull/9932/files/9b4e941d..1f4cdd96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=06-07 Stats: 13 lines in 1 file changed: 3 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9932.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9932/head:pull/9932 PR: https://git.openjdk.org/jdk/pull/9932 From dnsimon at openjdk.org Mon Aug 22 20:46:26 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 22 Aug 2022 20:46:26 GMT Subject: RFR: 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter [v2] In-Reply-To: References: Message-ID: On Sat, 23 Jul 2022 07:58:05 GMT, Erik Gahlin wrote: >> 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: >> >> support special linkage rules for jdk.jfr.internal.event.EventWriterFactory.getEventWriter(long) in JVMCI > > This is probably best reviewed by Markus as he did the implementation for C1/C2. He is on vacation, but will be back sometime in august. Thanks for the reviews @egahlin and @mgronlun. ------------- PR: https://git.openjdk.org/jdk/pull/9449 From dholmes at openjdk.org Mon Aug 22 20:58:23 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Aug 2022 20:58:23 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 17:06:51 GMT, Johan Sj?l?n wrote: >> test/hotspot/gtest/threadHelper.inline.hpp line 148: >> >>> 146: }; >>> 147: >>> 148: // A TestThreadGroup tracks multiple threads running the same function. >> >> So we have F, which is kind of clear, S, which is a state?, and then also a state generator? Which apparently needs to define operator () and return a state? Could you please document what the template parameters are and what is expected of them? >> >> Does N really need to be a template parameter? You lose flexibility, and it is less readable too. > >>So we have F, which is kind of clear, S, which is a state?, and then also a state generator? Which apparently needs to define operator () and return a state? > > Let me explain my reasoning, call me out if something seems odd please! > > A `BasicTestThread` has a F, the code which runs, and S, the local state which is only available for F. A ?TestThreadGroup` let's you create many `BasicTestThread` for the same F, but with varying S, with the help of a state generator. > > Subclasses (the "old" way) are good at having their own local state, whilst lambdas are good at sharing state (through their access to the lexical environment they're created in). The whole S and state generator business is kind of a crutch to help lambdas out to be more like subclasses. Maybe there's a bit of YAGNI here, and really it's fine if `TestThreadGroup` also gets an S like `BasicTestThread` does? > >>Could you please document what the template parameters are and what is expected of them? > > Absolutely. I'll also lengthen their name, to make them more clear- > >>Does N really need to be a template parameter? You lose flexibility, and it is less readable too. > > What flexibility are we losing? We're not going to be dynamically reallocate the amount of threads in a `TestThreadGroup`, or is this the exact use case you're imagining in the future? > > I don't think it's necessarily less readable. It's fairly standard in C++ STL to use template arguments for sizes (see `std::array`). I know we typically use raw pointers and length variables in Hotspot, so it's certainly unidiomatic from those eyes. To me, it's more readable, because it's a hint to me that "aha, this size won't change during execution". The experience of developers with templates and STL will vary widely - just something to bear in mind when modernising the codebase. :) I found it harder to "spot the threads" in the new style. ------------- PR: https://git.openjdk.org/jdk/pull/9962 From vlivanov at openjdk.org Mon Aug 22 23:49:27 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 22 Aug 2022 23:49:27 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v9] In-Reply-To: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: > (PR depends on #9923.) > > Constants which reside outside code cache are not guaranteed to be reachable in > RIP-relative addressing mode from stub code, but absolute addressing mode requires a > scratch register. > > Provide a scratch register to ensure constants are reachable irrespective of > process memory layout. > > Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. > > Testing: > - [x] hs-tier1 - hs-tier4 > - [x] x86_32 hotspot build Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: code buffer outside code cache ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9932/files - new: https://git.openjdk.org/jdk/pull/9932/files/1f4cdd96..3a9340fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=07-08 Stats: 35 lines in 1 file changed: 4 ins; 19 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9932.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9932/head:pull/9932 PR: https://git.openjdk.org/jdk/pull/9932 From vlivanov at openjdk.org Mon Aug 22 23:54:27 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 22 Aug 2022 23:54:27 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v3] In-Reply-To: References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: On Fri, 19 Aug 2022 20:02:38 GMT, Vladimir Kozlov wrote: > I would suggest to run full tier1-4 mach5 testing (instead of only hs-tier*) which will run java/lang/math tests too. And tier4 runs with -Xcomp. I ran it through tier1 - tier4 and the results look fine. ------------- PR: https://git.openjdk.org/jdk/pull/9932 From vlivanov at openjdk.org Mon Aug 22 23:54:31 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 22 Aug 2022 23:54:31 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v4] In-Reply-To: References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: On Mon, 22 Aug 2022 11:29:17 GMT, Aleksey Shipilev wrote: >> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Merge branch 'master' into trig_rscratch >> - rscratch >> - cmp64 >> - 8292638: x86: Improve scratch register handling in VM stubs >> - StubRoutines cleanup >> - tabs >> - x86: Improve handling of constants in trigonometric stubs > > src/hotspot/cpu/x86/assembler_x86.cpp line 12244: > >> 12242: } >> 12243: >> 12244: bool Assembler::always_reachable(AddressLiteral adr) { > > So, there is a similar block in `Assembler::is_reachable_from` -- does it make sense to reuse it then? They also are subtly different on the use of `ForceUnreachable`, would this method return different result compared to `Assembler::is_reachable_from`, and thus fail the assert in `Assembler::reachable`? As it is now, `ForceUnreachable` works fine. There's one implicit assumption which makes it work though: temporary code buffer has to reside in code cache which is always the case now. Otherwise, `always_reachable` would have to take `pc` into account as well. I propose to make it a requirement for the code buffer to be placed in the code cache and simplify the reachability checks based on that. (Latest version reflects the proposal.) ------------- PR: https://git.openjdk.org/jdk/pull/9932 From dholmes at openjdk.org Tue Aug 23 01:41:30 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 23 Aug 2022 01:41:30 GMT Subject: RFR: JDK-8292351: tty should always live [v6] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 15:45:25 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Last changes Looks good. Thank for your patience and perseverance on this one. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9874 From dholmes at openjdk.org Tue Aug 23 01:54:34 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 23 Aug 2022 01:54:34 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v2] In-Reply-To: <03PIk7Zf62XvKZjoRob4OfixPKpshirPOrxzzOOsrgU=.7be8cb20-7aa2-4765-a7e0-6fe527d143ba@github.com> References: <03PIk7Zf62XvKZjoRob4OfixPKpshirPOrxzzOOsrgU=.7be8cb20-7aa2-4765-a7e0-6fe527d143ba@github.com> Message-ID: On Fri, 19 Aug 2022 15:34:45 GMT, Johan Sj?l?n wrote: >> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? >> >> This PR does 3 things: >> >> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot >> * Adds some new utilities for writing multi-threaded tests. >> * Adds some tests for MRSW Mutex using these new utilities >> >> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 >> >> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Review comments src/hotspot/share/utilities/readWriteLock.hpp line 26: > 24: > 25: #ifndef SHARE_RUNTIME_MRSWMUTEX_HPP > 26: #define SHARE_RUNTIME_MRSWMUTEX_HPP The include guards need updating to reflect the file renaming. (thanks for that) src/hotspot/share/utilities/readWriteLock.hpp line 45: > 43: private: > 44: NONCOPYABLE(ReadWriteLock); > 45: class NoTransition : public StackObj { This is dead code now. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From stuefe at openjdk.org Tue Aug 23 05:06:30 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Aug 2022 05:06:30 GMT Subject: RFR: JDK-8292351: tty should always live [v6] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 15:45:25 GMT, Thomas Stuefe wrote: >> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. >> >> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. >> >> tty should always be safe to write to, and that is trivial to do. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Last changes I'm happy we have a compromise. ------------- PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Tue Aug 23 05:07:49 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Aug 2022 05:07:49 GMT Subject: Integrated: JDK-8292351: tty should always live In-Reply-To: References: Message-ID: <78Q6IGLgNLNvUUNrO1tnMZ01I1znHyU0I1xWzNpTnfQ=.f3b0a1ab-8c15-4950-b9fa-77ab59c39ec3@github.com> On Mon, 15 Aug 2022 09:25:17 GMT, Thomas Stuefe wrote: > The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes. > > This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging. > > tty should always be safe to write to, and that is trivial to do. This pull request has now been integrated. Changeset: a85a7234 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/a85a72341bd840b2c7b66ce32c8bbca920e519c8 Stats: 35 lines in 2 files changed: 28 ins; 1 del; 6 mod 8292351: tty should always live Reviewed-by: clanger, coleenp, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/9874 From stuefe at openjdk.org Tue Aug 23 07:10:32 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Aug 2022 07:10:32 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 20:55:06 GMT, David Holmes wrote: > The experience of developers with templates and STL will vary widely - just something to bear in mind when modernising the codebase. :) I found it harder to "spot the threads" in the new style. Over-templatizing stuff is as bad as not using templates where they make sense. One negative effect, not the only one: it makes builds take longer, which is a tax every developer has to pay many times over. Not long ago, JDK builds used to be done in ~2.5 minutes on my fast machine, and now I'm up to almost 4 minutes. This, too, is death by a thousand cuts. Other effects include APIs that are harder to read since template parameters are often undocumented. IDEs have a harder time coping. And code may become harder to re-use since what should be runtime decisions get baked into the code in the form of template args. ------------- PR: https://git.openjdk.org/jdk/pull/9962 From dnsimon at openjdk.org Tue Aug 23 07:28:11 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 23 Aug 2022 07:28:11 GMT Subject: Integrated: 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter In-Reply-To: References: Message-ID: <77WqgnluscjSLOcaalLB0UtCYLYOZeqDom6mrs6uP3I=.b6be7381-4c9a-4adf-862e-180255dd746d@github.com> On Mon, 11 Jul 2022 11:12:34 GMT, Doug Simon wrote: > [JDK-8282420](https://bugs.openjdk.org/browse/JDK-8282420) introduced the notion of "blessed methods" which are those that can link against `jdk.jfr.internal.event.EventWriterFactory.getEventWriter(long)`. > This PR enhances the JVMCI ConstantPool API so that it can take a caller context when resolving a method to enforce this constraint properly. This pull request has now been integrated. Changeset: 259ba86c Author: Doug Simon URL: https://git.openjdk.org/jdk/commit/259ba86c60c9f17ac7302f73cd1e3532474c9f18 Stats: 146 lines in 12 files changed: 127 ins; 6 del; 13 mod 8290075: [JVMCI] only blessed methods can link against EventWriterFactory.getEventWriter Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/9449 From stuefe at openjdk.org Tue Aug 23 07:32:21 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Aug 2022 07:32:21 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 17:06:51 GMT, Johan Sj?l?n wrote: >> test/hotspot/gtest/threadHelper.inline.hpp line 148: >> >>> 146: }; >>> 147: >>> 148: // A TestThreadGroup tracks multiple threads running the same function. >> >> So we have F, which is kind of clear, S, which is a state?, and then also a state generator? Which apparently needs to define operator () and return a state? Could you please document what the template parameters are and what is expected of them? >> >> Does N really need to be a template parameter? You lose flexibility, and it is less readable too. > >>So we have F, which is kind of clear, S, which is a state?, and then also a state generator? Which apparently needs to define operator () and return a state? > > Let me explain my reasoning, call me out if something seems odd please! > > A `BasicTestThread` has a F, the code which runs, and S, the local state which is only available for F. A ?TestThreadGroup` let's you create many `BasicTestThread` for the same F, but with varying S, with the help of a state generator. > > Subclasses (the "old" way) are good at having their own local state, whilst lambdas are good at sharing state (through their access to the lexical environment they're created in). The whole S and state generator business is kind of a crutch to help lambdas out to be more like subclasses. Maybe there's a bit of YAGNI here, and really it's fine if `TestThreadGroup` also gets an S like `BasicTestThread` does? > >>Could you please document what the template parameters are and what is expected of them? > > Absolutely. I'll also lengthen their name, to make them more clear- > >>Does N really need to be a template parameter? You lose flexibility, and it is less readable too. > > What flexibility are we losing? We're not going to be dynamically reallocate the amount of threads in a `TestThreadGroup`, or is this the exact use case you're imagining in the future? > > I don't think it's necessarily less readable. It's fairly standard in C++ STL to use template arguments for sizes (see `std::array`). I know we typically use raw pointers and length variables in Hotspot, so it's certainly unidiomatic from those eyes. To me, it's more readable, because it's a hint to me that "aha, this size won't change during execution". Hi @jdksjolen, > > So we have F, which is kind of clear, S, which is a state?, and then also a state generator? Which apparently needs to define operator () and return a state? > > Let me explain my reasoning, call me out if something seems odd please! > > A `BasicTestThread` has a F, the code which runs, and S, the local state which is only available for F. A ?TestThreadGroup`let's you create many`BasicTestThread` for the same F, but with varying S, with the help of a state generator. Okay, I see. Thanks for clarifying. All examples atm hand out the same state to the individual threads though. Do we have many examples where we have different states? One simpler, more pragmatic way would be for the thread group to give each started thread a numeric id. Most of the cases I can think of would be happy with that, using the id inside the thread function to control behavior. > > Subclasses (the "old" way) are good at having their own local state, whilst lambdas are good at sharing state (through their access to the lexical environment they're created in). The whole S and state generator business is kind of a crutch to help lambdas out to be more like subclasses. Maybe there's a bit of YAGNI here, and really it's fine if `TestThreadGroup` also gets an S like `BasicTestThread` does? Well, I don't see why this would have to be templatized at all; normal inheritance and interfaces would work just as well. At least with the examples given, I don't see the performance advantage. That's not to say that I'm against it, the in-function lambda syntax is certainly nice. > > > Could you please document what the template parameters are and what is expected of them? > > Absolutely. I'll also lengthen their name, to make them more clear- > > > Does N really need to be a template parameter? You lose flexibility, and it is less readable too. > > What flexibility are we losing? We're not going to be dynamically reallocate the amount of threads in a `TestThreadGroup`, or is this the exact use case you're imagining in the future? The ability to start with the number of threads dictated at runtime, depending on runtime conditions. The ability to reuse the same TTG in different subtests with different thread numbers without template bloat. Actually, the same argument goes for F. This design still requires us to use the same thread function for all threads. For cases where you want to have multiple different thread functions, you would still end up with some sort of switch inside the thread function. If F were a runtime thing, you could do something like this: TTG.add_threads(12, functorX); // add 12 threads that do X TTG.add_threads(6, functorY); // add 12 threads that do Y i.e., add multiple threads with multiple functions to the same thread group and control them all via TTG. > > I don't think it's necessarily less readable. It's fairly standard in C++ STL to use template arguments for sizes (see `std::array`). I know we typically use raw pointers and length variables in Hotspot, so it's certainly unidiomatic from those eyes. To me, it's more readable, because it's a hint to me that "aha, this size won't change during execution". As I wrote in the other comment, opinions vary on this, and we have many devs who need to maintain the code base. ------------- PR: https://git.openjdk.org/jdk/pull/9962 From cstein at openjdk.org Tue Aug 23 07:56:03 2022 From: cstein at openjdk.org (Christian Stein) Date: Tue, 23 Aug 2022 07:56:03 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v3] In-Reply-To: References: Message-ID: > Please review the change to update to using jtreg 7. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. Christian Stein 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 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Revert junit.java Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Update to new JUnit JAR file With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2"). This change updates the hard-coded library tag value to the new JUnit JAR file. Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316, in order to unblock the "Update to use jtreg 7" PR 9393: https://github.com/openjdk/jdk/pull/9393 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Update github-actions.conf - ... and 1 more: https://git.openjdk.org/jdk/compare/486f90c1...468f0bd3 ------------- Changes: https://git.openjdk.org/jdk/pull/9393/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=02 Stats: 10 lines in 7 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/9393.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393 PR: https://git.openjdk.org/jdk/pull/9393 From cstein at openjdk.org Tue Aug 23 07:58:20 2022 From: cstein at openjdk.org (Christian Stein) Date: Tue, 23 Aug 2022 07:58:20 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v4] In-Reply-To: References: Message-ID: <20AQsJGMltW6Z6Ml-SDdXFJ81F83MnHmCl524jLvECA=.5f72fc0c-e973-45d1-92e4-e3f383d727ad@github.com> > Please review the change to update to using jtreg 7. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Update configure to check for jtreg 7 or later ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9393/files - new: https://git.openjdk.org/jdk/pull/9393/files/468f0bd3..1f6f4a7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9393.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393 PR: https://git.openjdk.org/jdk/pull/9393 From mdoerr at openjdk.org Tue Aug 23 09:01:29 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 23 Aug 2022 09:01:29 GMT Subject: Integrated: 8292368: [ppc64] internal error g1BarrierSet.inline.hpp assert(oopDesc::is_oop(pre_val, true)) failed: Error In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 17:23:47 GMT, Martin Doerr wrote: > C1 patching stubs contain null Oops on PPC64. Null check is missing in [JDK-8292077](https://bugs.openjdk.org/browse/JDK-8292077). This pull request has now been integrated. Changeset: cf006774 Author: Martin Doerr URL: https://git.openjdk.org/jdk/commit/cf0067741249cc3260b1d220769dac408b614f22 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8292368: [ppc64] internal error g1BarrierSet.inline.hpp assert(oopDesc::is_oop(pre_val, true)) failed: Error Reviewed-by: eosterlund, shade ------------- PR: https://git.openjdk.org/jdk/pull/9968 From cstein at openjdk.org Tue Aug 23 11:22:55 2022 From: cstein at openjdk.org (Christian Stein) Date: Tue, 23 Aug 2022 11:22:55 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5] In-Reply-To: References: Message-ID: > Please review the change to update to using jtreg 7. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Update configure to check for jtreg 7 or later - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Revert junit.java Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Update to new JUnit JAR file With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2"). This change updates the hard-coded library tag value to the new JUnit JAR file. Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316, in order to unblock the "Update to use jtreg 7" PR 9393: https://github.com/openjdk/jdk/pull/9393 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - ... and 3 more: https://git.openjdk.org/jdk/compare/cf006774...bbf53448 ------------- Changes: https://git.openjdk.org/jdk/pull/9393/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=04 Stats: 11 lines in 8 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/9393.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393 PR: https://git.openjdk.org/jdk/pull/9393 From chagedorn at openjdk.org Tue Aug 23 13:34:55 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 23 Aug 2022 13:34:55 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v15] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 08:07:52 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: >> >> Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> >> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. >> >> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): >> >> Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) >> >> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. >> >> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf >> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. >> >> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. >> >> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. >> >> **Testing:** >> Apart from manual testing, I've added two kinds of tests: >> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. >> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. >> >> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. >> >> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. >> >> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). >> >> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits: > > - Merge branch 'master' into JDK-8242181 > - Fix optimized build > - Merge branch 'master' into JDK-8242181 > - Merge branch 'master' into JDK-8242181 > - Exclude TestDwarf.java when run with product because TraceDwarf is a develop flag > - Merge branch 'master' into JDK-8242181 > - Merge branch 'master' into JDK-8242181 > - Fix TestDwarf for older GCC versions > - Change logging from UL to tty based with new TraceDwarfLevel develop flag > - Add support to parse the .debug_line section in DWARF 2 as emitted by GCC 8, add some comments > - ... and 62 more: https://git.openjdk.org/jdk/compare/d1edda8f...d4a4e873 Testing in our CI looked good. I've also tested it again locally on x86_32. I will integrate this tomorrow morning. ------------- PR: https://git.openjdk.org/jdk/pull/7126 From duke at openjdk.org Tue Aug 23 14:23:41 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Tue, 23 Aug 2022 14:23:41 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way In-Reply-To: References: Message-ID: <4l8A-A681OjSXf66SczAAIpcn-vVT2DYVVsOLXrF-Dk=.44b3f897-5433-446c-bcab-285341ae6397@github.com> On Tue, 23 Aug 2022 07:29:10 GMT, Thomas Stuefe wrote: >One simpler, more pragmatic way would be for the thread group to give each started thread a numeric id. Most of the cases I can think of would be happy with that, using the id inside the thread function to control behavior. That might be sufficient. Looking through the test cases, they're either too complex for me to take the time to understand for this discussion, or would work OK with this kind of id. I'm thinking for N threads, each threads gets a unique id in the range `[0,N)`, are we thinking the same thing? >The ability to start with the number of threads dictated at runtime, depending on runtime conditions. The ability to reuse the same TTG in different subtests with different thread numbers without template bloat. There's probably no significant gain to be had in re-using the same TTG in different subtests, but I see the value of minimizing compilation times by not having several monomorphizations depending on N. >Actually, the same argument goes for F. This design still requires us to use the same thread function for all threads. For cases where you want to have multiple different thread functions, you would still end up with some sort of switch inside the thread function. If F were a runtime thing, you could do something like this: That's flexible, but not easier to understand. Suddenly, several `doit()` and several `join()`s are viable, it makes the semantics of TTG way more complicated. Simple tests are preferable, I'd keep `F` if it meant that we *can't* add two different functors to a TTG. We *can* get rid of `F`, as so: #include template class BasicTestThread : public JavaTestThread { std::function f; }; Unfortunately `std::function` is a no go, but it does show an enticing way forward. It would be useful in many places of Hotspot, probably having a real build time improvement. Here's my plan: - Move N out from being a template parameter to a constructor argument - Try to remove S and instead use a numeric id, see how the two solutions differ for these test cases. If it's nice, I'll also remove S (and therefore also state generator, for example). - I'm keeping F, no changes there. ------------- PR: https://git.openjdk.org/jdk/pull/9962 From coleenp at openjdk.org Tue Aug 23 14:53:06 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Aug 2022 14:53:06 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable Message-ID: This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. I added a test for printing dictionary statistics. This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. ------------- Commit messages: - Use ConcurrentHashtable for Dictionary Changes: https://git.openjdk.org/jdk/pull/9886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9886&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292680 Stats: 608 lines in 29 files changed: 255 ins; 181 del; 172 mod Patch: https://git.openjdk.org/jdk/pull/9886.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9886/head:pull/9886 PR: https://git.openjdk.org/jdk/pull/9886 From stuefe at openjdk.org Tue Aug 23 14:58:26 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Aug 2022 14:58:26 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way In-Reply-To: <4l8A-A681OjSXf66SczAAIpcn-vVT2DYVVsOLXrF-Dk=.44b3f897-5433-446c-bcab-285341ae6397@github.com> References: <4l8A-A681OjSXf66SczAAIpcn-vVT2DYVVsOLXrF-Dk=.44b3f897-5433-446c-bcab-285341ae6397@github.com> Message-ID: On Tue, 23 Aug 2022 14:20:17 GMT, Johan Sj?l?n wrote: > > One simpler, more pragmatic way would be for the thread group to give each started thread a numeric id. Most of the cases I can think of would be happy with that, using the id inside the thread function to control behavior. > > That might be sufficient. Looking through the test cases, they're either too complex for me to take the time to understand for this discussion, or would work OK with this kind of id. I'm thinking for N threads, each threads gets a unique id in the range `[0,N)`, are we thinking the same thing? Yes. At least the tests I wrote, I usually had like one thread that would do A, the rest B, or half/half would do A or B. That can be just controlled via the running id. Beside its nice for debugging. > > > The ability to start with the number of threads dictated at runtime, depending on runtime conditions. The ability to reuse the same TTG in different subtests with different thread numbers without template bloat. > > There's probably no significant gain to be had in re-using the same TTG in different subtests, but I see the value of minimizing compilation times by not having several monomorphizations depending on N. Not sure what you meant with the first half of the sentence. But one example for controlling num threads at runtime, I think now that we add more and more functionality to gtest, we may need a way to control the test width. Reduce the number of concurrent threads. There are folks running these tests as part of their build on tiny make machines. Of course, canonical test results would still require a certain number of concurrent tests. > > > Actually, the same argument goes for F. This design still requires us to use the same thread function for all threads. For cases where you want to have multiple different thread functions, you would still end up with some sort of switch inside the thread function. If F were a runtime thing, you could do something like this: > > That's flexible, but not easier to understand. Suddenly, several `doit()` and several `join()`s are viable, it makes the semantics of TTG way more complicated. Simple tests are preferable, I'd keep `F` if it meant that we _can't_ add two different functors to a TTG. Ok, I agree. > > We _can_ get rid of `F`, as so: > > ``` > #include > > template > class BasicTestThread : public JavaTestThread { > std::function f; > }; > ``` > > Unfortunately `std::function` is a no go, but it does show an enticing way forward. It would be useful in many places of Hotspot, probably having a real build time improvement. > > Here's my plan: > > * Move N out from being a template parameter to a constructor argument > * Try to remove S and instead use a numeric id, see how the two solutions differ for these test cases. If it's nice, I'll also remove S (and therefore also state generator, for example). > * I'm keeping F, no changes there. Sounds good. Thanks for considering this. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/9962 From coleenp at openjdk.org Tue Aug 23 15:02:32 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Aug 2022 15:02:32 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way In-Reply-To: References: <4l8A-A681OjSXf66SczAAIpcn-vVT2DYVVsOLXrF-Dk=.44b3f897-5433-446c-bcab-285341ae6397@github.com> Message-ID: On Tue, 23 Aug 2022 14:54:49 GMT, Thomas Stuefe wrote: >>>One simpler, more pragmatic way would be for the thread group to give each started thread a numeric id. Most of the cases I can think of would be happy with that, using the id inside the thread function to control behavior. >> >> That might be sufficient. Looking through the test cases, they're either too complex for me to take the time to understand for this discussion, or would work OK with this kind of id. I'm thinking for N threads, each threads gets a unique id in the range `[0,N)`, are we thinking the same thing? >> >>>The ability to start with the number of threads dictated at runtime, depending on runtime conditions. The ability to reuse the same TTG in different subtests with different thread numbers without template bloat. >> >> There's probably no significant gain to be had in re-using the same TTG in different subtests, but I see the value of minimizing compilation times by not having several monomorphizations depending on N. >> >>>Actually, the same argument goes for F. This design still requires us to use the same thread function for all threads. For cases where you want to have multiple different thread functions, you would still end up with some sort of switch inside the thread function. If F were a runtime thing, you could do something like this: >> >> That's flexible, but not easier to understand. Suddenly, several `doit()` and several `join()`s are viable, it makes the semantics of TTG way more complicated. Simple tests are preferable, I'd keep `F` if it meant that we *can't* add two different functors to a TTG. >> >> We *can* get rid of `F`, as so: >> >> >> #include >> >> template >> class BasicTestThread : public JavaTestThread { >> std::function f; >> }; >> >> >> Unfortunately `std::function` is a no go, but it does show an enticing way forward. It would be useful in many places of Hotspot, probably having a real build time improvement. >> >> >> Here's my plan: >> >> - Move N out from being a template parameter to a constructor argument >> - Try to remove S and instead use a numeric id, see how the two solutions differ for these test cases. If it's nice, I'll also remove S (and therefore also state generator, for example). >> - I'm keeping F, no changes there. > >> > One simpler, more pragmatic way would be for the thread group to give each started thread a numeric id. Most of the cases I can think of would be happy with that, using the id inside the thread function to control behavior. >> >> That might be sufficient. Looking through the test cases, they're either too complex for me to take the time to understand for this discussion, or would work OK with this kind of id. I'm thinking for N threads, each threads gets a unique id in the range `[0,N)`, are we thinking the same thing? > > Yes. At least the tests I wrote, I usually had like one thread that would do A, the rest B, or half/half would do A or B. That can be just controlled via the running id. Beside its nice for debugging. > >> >> > The ability to start with the number of threads dictated at runtime, depending on runtime conditions. The ability to reuse the same TTG in different subtests with different thread numbers without template bloat. >> >> There's probably no significant gain to be had in re-using the same TTG in different subtests, but I see the value of minimizing compilation times by not having several monomorphizations depending on N. > > Not sure what you meant with the first half of the sentence. But one example for controlling num threads at runtime, I think now that we add more and more functionality to gtest, we may need a way to control the test width. Reduce the number of concurrent threads. There are folks running these tests as part of their build on tiny make machines. Of course, canonical test results would still require a certain number of concurrent tests. > >> >> > Actually, the same argument goes for F. This design still requires us to use the same thread function for all threads. For cases where you want to have multiple different thread functions, you would still end up with some sort of switch inside the thread function. If F were a runtime thing, you could do something like this: >> >> That's flexible, but not easier to understand. Suddenly, several `doit()` and several `join()`s are viable, it makes the semantics of TTG way more complicated. Simple tests are preferable, I'd keep `F` if it meant that we _can't_ add two different functors to a TTG. > > Ok, I agree. > >> >> We _can_ get rid of `F`, as so: >> >> ``` >> #include >> >> template >> class BasicTestThread : public JavaTestThread { >> std::function f; >> }; >> ``` >> >> Unfortunately `std::function` is a no go, but it does show an enticing way forward. It would be useful in many places of Hotspot, probably having a real build time improvement. >> >> Here's my plan: >> >> * Move N out from being a template parameter to a constructor argument >> * Try to remove S and instead use a numeric id, see how the two solutions differ for these test cases. If it's nice, I'll also remove S (and therefore also state generator, for example). >> * I'm keeping F, no changes there. > > Sounds good. Thanks for considering this. > > Cheers, Thomas I have to say that as someone who just learned what declspec was yesterday, a little bit of documentation would help to know what the template parameters should be, but otherwise, this is much better than copying and pasting the thread group code with semaphores. Writing the lambda to do the task, and the number of threads to do that is very nice. Maybe the example changes should give a name to the second lambda for StateFunc. I agree builds are getting really slow though, but I don't know if this makes it worse. I'd rather not copy this code. ------------- PR: https://git.openjdk.org/jdk/pull/9962 From duke at openjdk.org Tue Aug 23 15:14:54 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Tue, 23 Aug 2022 15:14:54 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive Message-ID: Please review this patch to fix the crash when running Loom with Shenandoah in iu+aggressive mode. 1. Always enable barrier for Shenandoah IU mode (this change is same as https://github.com/openjdk/jdk/pull/9494), but is not sufficient to prevent the assertion failure. 2. Run barriers for oops in stack chunk header. The code in `stackChunkOopDesc::do_barriers` is missing barriers on the oops present in the stack chunk header. Signed-off-by: Ashutosh Mehra ------------- Commit messages: - 8288129: Shenandoah: Skynet test crashed with iu + aggressive Changes: https://git.openjdk.org/jdk/pull/9982/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9982&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288129 Stats: 39 lines in 3 files changed: 39 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9982/head:pull/9982 PR: https://git.openjdk.org/jdk/pull/9982 From kvn at openjdk.org Tue Aug 23 15:55:28 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 23 Aug 2022 15:55:28 GMT Subject: RFR: 8292671: Hotspot Style Guide should allow covariant returns In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 14:12:05 GMT, Roland Westrelin wrote: > The style guide explicitly lists covariant returns as a disallowed > feature of c++. I propose we allow that feature. > > This came up on the c2 side where, with JDK-8275201, I introduced some > uses of covariant returns at a number of locations in the c2 code > because I felt the code was cleaner that way. I wasn't aware it was > mentioned on the style guide. This was noticed by another openjdk > contributor and I prepared a change to revert the use of covariant > returns I had introduced: > > https://github.com/openjdk/jdk/pull/9237 > > But it feels that change actually makes the code less clear and > comments on the PR indicates some other contributors feel the same > way. > > It's unclear to me why covariant returns are disallowed in the first > place and the (few) contributors I asked don't seem to know either. So > I propose simply allowing covariant returns. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9941 From kvn at openjdk.org Tue Aug 23 16:01:31 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 23 Aug 2022 16:01:31 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v9] In-Reply-To: References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: On Mon, 22 Aug 2022 23:49:27 GMT, Vladimir Ivanov wrote: >> (PR depends on #9923.) >> >> Constants which reside outside code cache are not guaranteed to be reachable in >> RIP-relative addressing mode from stub code, but absolute addressing mode requires a >> scratch register. >> >> Provide a scratch register to ensure constants are reachable irrespective of >> process memory layout. >> >> Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 >> - [x] x86_32 hotspot build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > code buffer outside code cache Good. Thank you for running additional testing. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9932 From shade at openjdk.org Tue Aug 23 16:15:28 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 23 Aug 2022 16:15:28 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v9] In-Reply-To: References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: <7kWCE9O2RU-eDeGZ1bWENM4LssCqGbj7zuMX2mctMLo=.d69da3f6-0857-4b24-afce-c55f5785078b@github.com> On Mon, 22 Aug 2022 23:49:27 GMT, Vladimir Ivanov wrote: >> (PR depends on #9923.) >> >> Constants which reside outside code cache are not guaranteed to be reachable in >> RIP-relative addressing mode from stub code, but absolute addressing mode requires a >> scratch register. >> >> Provide a scratch register to ensure constants are reachable irrespective of >> process memory layout. >> >> Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 >> - [x] x86_32 hotspot build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > code buffer outside code cache Looks good, a few nits: `is_reachable_from` vs `is_always_reachable`: these look like siblings, so they probably should both either have `_from`, or both skip it. I don't see why would we need to do `tmp /* rscratch */` comments everywhere, looks like noise. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9932 From vlivanov at openjdk.org Tue Aug 23 17:01:31 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Aug 2022 17:01:31 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v10] In-Reply-To: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: > (PR depends on #9923.) > > Constants which reside outside code cache are not guaranteed to be reachable in > RIP-relative addressing mode from stub code, but absolute addressing mode requires a > scratch register. > > Provide a scratch register to ensure constants are reachable irrespective of > process memory layout. > > Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. > > Testing: > - [x] hs-tier1 - hs-tier4 > - [x] x86_32 hotspot build Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: is_reachable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9932/files - new: https://git.openjdk.org/jdk/pull/9932/files/3a9340fc..ee3b17c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9932&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9932.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9932/head:pull/9932 PR: https://git.openjdk.org/jdk/pull/9932 From shade at openjdk.org Tue Aug 23 17:14:20 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 23 Aug 2022 17:14:20 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v10] In-Reply-To: References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: On Tue, 23 Aug 2022 17:01:31 GMT, Vladimir Ivanov wrote: >> (PR depends on #9923.) >> >> Constants which reside outside code cache are not guaranteed to be reachable in >> RIP-relative addressing mode from stub code, but absolute addressing mode requires a >> scratch register. >> >> Provide a scratch register to ensure constants are reachable irrespective of >> process memory layout. >> >> Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 >> - [x] x86_32 hotspot build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > is_reachable Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9932 From vlivanov at openjdk.org Tue Aug 23 17:14:21 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Aug 2022 17:14:21 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v9] In-Reply-To: <7kWCE9O2RU-eDeGZ1bWENM4LssCqGbj7zuMX2mctMLo=.d69da3f6-0857-4b24-afce-c55f5785078b@github.com> References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> <7kWCE9O2RU-eDeGZ1bWENM4LssCqGbj7zuMX2mctMLo=.d69da3f6-0857-4b24-afce-c55f5785078b@github.com> Message-ID: On Tue, 23 Aug 2022 16:12:01 GMT, Aleksey Shipilev wrote: > is_reachable_from vs is_always_reachable: these look like siblings, so they probably should both either have _from, or both skip it. Agree. Once I removed current location argument, `_from` doesn't make any sense anymore. > I don't see why would we need to do tmp /* rscratch */ comments everywhere, looks like noise. I prefer to keep it for documentary purposes. IMO it clearly points at rip-relative addressing being at play here and hints that the address is not always reachable (which can be acted upon to eliminate the usage). ------------- PR: https://git.openjdk.org/jdk/pull/9932 From coleenp at openjdk.org Tue Aug 23 17:20:14 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Aug 2022 17:20:14 GMT Subject: RFR: 8292790: Remove hashtable.hpp from other files Message-ID: These includes are no longer needed or haven't been needed for a while. Tested arm cross-compile, and tier1 with Oracle platforms in progress, also GHA. Please review this change which is trivial if the test results are clean. ------------- Commit messages: - 8292790: Remove hashtable.hpp from other files Changes: https://git.openjdk.org/jdk/pull/9986/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9986&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292790 Stats: 10 lines in 8 files changed: 0 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9986.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9986/head:pull/9986 PR: https://git.openjdk.org/jdk/pull/9986 From shade at openjdk.org Tue Aug 23 18:00:46 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 23 Aug 2022 18:00:46 GMT Subject: RFR: 8292790: Remove hashtable.hpp from other files In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 17:13:46 GMT, Coleen Phillimore wrote: > These includes are no longer needed or haven't been needed for a while. Tested arm cross-compile, and tier1 with Oracle platforms in progress, also GHA. Please review this change which is trivial if the test results are clean. Looks good. (I tested a battery of hotspot cross-compilation tests, without failures). ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9986 From hseigel at openjdk.org Tue Aug 23 18:09:20 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 23 Aug 2022 18:09:20 GMT Subject: RFR: 8292790: Remove hashtable.hpp from other files In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 17:13:46 GMT, Coleen Phillimore wrote: > These includes are no longer needed or haven't been needed for a while. Tested arm cross-compile, and tier1 with Oracle platforms in progress, also GHA. Please review this change which is trivial if the test results are clean. LGTM ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.org/jdk/pull/9986 From coleenp at openjdk.org Tue Aug 23 18:26:06 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Aug 2022 18:26:06 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v2] In-Reply-To: References: Message-ID: > This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. > > Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. > I added a test for printing dictionary statistics. > > This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Conditionalize scanning function call for safepoint. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9886/files - new: https://git.openjdk.org/jdk/pull/9886/files/2e8f865b..8ddba734 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9886&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9886&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9886.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9886/head:pull/9886 PR: https://git.openjdk.org/jdk/pull/9886 From coleenp at openjdk.org Tue Aug 23 18:41:40 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Aug 2022 18:41:40 GMT Subject: RFR: 8292790: Remove hashtable.hpp from other files In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 17:13:46 GMT, Coleen Phillimore wrote: > These includes are no longer needed or haven't been needed for a while. Tested arm cross-compile, and tier1 with Oracle platforms in progress, also GHA. Please review this change which is trivial if the test results are clean. Thanks for testing Aleksey and the review Harold. Our internal tests passed. The GHAs are taking longer. I guess I'll wait an hour. ------------- PR: https://git.openjdk.org/jdk/pull/9986 From ihse at openjdk.org Tue Aug 23 19:00:38 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 23 Aug 2022 19:00:38 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5] In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 11:22:55 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 7. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Update configure to check for jtreg 7 or later > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Revert junit.java > > Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Update to new JUnit JAR file > > With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2"). > This change updates the hard-coded library tag value to the new JUnit JAR file. > Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316, > in order to unblock the "Update to use jtreg 7" PR 9393: > https://github.com/openjdk/jdk/pull/9393 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - ... and 3 more: https://git.openjdk.org/jdk/compare/cf006774...bbf53448 Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9393 From vlivanov at openjdk.org Tue Aug 23 19:35:52 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Aug 2022 19:35:52 GMT Subject: RFR: 8292638: x86: Improve scratch register handling in VM stubs [v10] In-Reply-To: References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: On Tue, 23 Aug 2022 17:01:31 GMT, Vladimir Ivanov wrote: >> (PR depends on #9923.) >> >> Constants which reside outside code cache are not guaranteed to be reachable in >> RIP-relative addressing mode from stub code, but absolute addressing mode requires a >> scratch register. >> >> Provide a scratch register to ensure constants are reachable irrespective of >> process memory layout. >> >> Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 >> - [x] x86_32 hotspot build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > is_reachable Thanks for the reviews, Vladimir and Aleksey. ------------- PR: https://git.openjdk.org/jdk/pull/9932 From vlivanov at openjdk.org Tue Aug 23 19:35:53 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Aug 2022 19:35:53 GMT Subject: Integrated: 8292638: x86: Improve scratch register handling in VM stubs In-Reply-To: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> References: <5LFXmw_B4WygZKHDlB0UtDp5byoHZCXMQaARkDbKVsM=.3f2c008d-5339-447e-aee3-983c67608281@github.com> Message-ID: On Thu, 18 Aug 2022 21:47:59 GMT, Vladimir Ivanov wrote: > (PR depends on #9923.) > > Constants which reside outside code cache are not guaranteed to be reachable in > RIP-relative addressing mode from stub code, but absolute addressing mode requires a > scratch register. > > Provide a scratch register to ensure constants are reachable irrespective of > process memory layout. > > Make scratch register usage explicit to make possible conflicts with surrounding stub code explicit. > > Testing: > - [x] hs-tier1 - hs-tier4 > - [x] x86_32 hotspot build This pull request has now been integrated. Changeset: f3be6731 Author: Vladimir Ivanov URL: https://git.openjdk.org/jdk/commit/f3be6731d3fa4fb1b7fc42c5bcbe6a64a50eaf42 Stats: 583 lines in 14 files changed: 76 ins; 212 del; 295 mod 8292638: x86: Improve scratch register handling in VM stubs Co-authored-by: Aleksey Shipilev Reviewed-by: kvn, shade ------------- PR: https://git.openjdk.org/jdk/pull/9932 From coleenp at openjdk.org Tue Aug 23 20:43:57 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Aug 2022 20:43:57 GMT Subject: RFR: 8292790: Remove hashtable.hpp from other files In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 17:13:46 GMT, Coleen Phillimore wrote: > These includes are no longer needed or haven't been needed for a while. Tested arm cross-compile, and tier1 with Oracle platforms in progress, also GHA. Please review this change which is trivial if the test results are clean. This is never going to finish but builds everywhere here. ------------- PR: https://git.openjdk.org/jdk/pull/9986 From coleenp at openjdk.org Tue Aug 23 20:43:58 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Aug 2022 20:43:58 GMT Subject: Integrated: 8292790: Remove hashtable.hpp from other files In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 17:13:46 GMT, Coleen Phillimore wrote: > These includes are no longer needed or haven't been needed for a while. Tested arm cross-compile, and tier1 with Oracle platforms in progress, also GHA. Please review this change which is trivial if the test results are clean. This pull request has now been integrated. Changeset: fe0544f8 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/fe0544f8a7db5bf0e93313e16b54b31bcdff946a Stats: 10 lines in 8 files changed: 0 ins; 8 del; 2 mod 8292790: Remove hashtable.hpp from other files Reviewed-by: shade, hseigel ------------- PR: https://git.openjdk.org/jdk/pull/9986 From mdoerr at openjdk.org Tue Aug 23 20:50:33 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 23 Aug 2022 20:50:33 GMT Subject: RFR: 8290025: Remove the Sweeper [v11] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 10:45:20 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund 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 'master' into 8290025_remove_sweeper > - Trigger GC from adapter blob allocations > - Zhengyu comments v1 > - Redundant variable > - Polish comment > - Merge branch 'master' into 8290025_remove_sweeper > - Removed more stale things > - Remove incorrect comment > - Feedback v2 > - Feedback v1 > - ... and 1 more: https://git.openjdk.org/jdk/compare/0c40128f...a06919b1 I haven't reviewed the whole PR (there were already enough reviews), but I like the sweeper removal and what I've seen looks good. Impressive how strongly the sweeper is interwoven with the rest of hotspot! I'll be glad to see it go away. Please note that there's a little more merging required after recent changes. I'd like to rerun it in our nightly testing and discuss with Thomas. Heuristics fine tuning could still be done as follow-up, but we should try to avoid major drawbacks. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/9741 From jbhateja at openjdk.org Wed Aug 24 00:14:18 2022 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 24 Aug 2022 00:14:18 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 Message-ID: Hi, This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. Kindly review and share your feedback. Best Regards, Jatin ------------- Commit messages: - 8291649: Removing failing tests from ProblemList-Xcomp.txt - 8291649: multiple tests failing with -Xcomp after JDK-8290034 Changes: https://git.openjdk.org/jdk/pull/9987/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9987&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291649 Stats: 175 lines in 5 files changed: 156 ins; 17 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9987.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9987/head:pull/9987 PR: https://git.openjdk.org/jdk/pull/9987 From pli at openjdk.org Wed Aug 24 00:50:31 2022 From: pli at openjdk.org (Pengfei Li) Date: Wed, 24 Aug 2022 00:50:31 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 09:33:58 GMT, Pengfei Li wrote: > Recently, an igvn infinite loop issue was reported. Git bisection shows > it appears after our JDK-8289996 patch. But after that patch is backed > out, we find similar test still fails. We have attached a jtreg case to > reproduce this issue. > > The ideal graph of the problematic method has a `MulINode` multiplying a > `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` > moves the constant input to the right hand side. And `Ideal()` function > in its parent class `MulNode` has the similar logic. In some code paths, > `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, > `MulINode` and `MulNode` use different ways to check constant. One calls > `type->singleton()` and the other calls `node->find_int_con(val)` which > accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` > can be evaluated to a constant, the two inputs of the `MulNode` will be > swapped back and forth in `Ideal()` calls. It eventually causes the igvn > infinite loop issue. > > This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` > because it's enough to do this by calling `MulNode::Ideal()`. We also do > some code cleanup in this patch as we have done in JDK-8289996. > > Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. PING. Any reviewer can help look at this? @shipilev ------------- PR: https://git.openjdk.org/jdk/pull/9820 From vlivanov at openjdk.org Wed Aug 24 03:48:17 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 24 Aug 2022 03:48:17 GMT Subject: RFR: 8292203: AArch64: Represent Registers as values [v5] In-Reply-To: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> Message-ID: > (It's a PR dependent on #9815.) > > Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation. > > The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types. > > Proposed change hides pointer representation behind value class. > > Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). > > Code quality improves: > GCC: https://godbolt.org/z/r6G36facj > Clang: https://godbolt.org/z/x5oPdYEPM > > (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) > > Testing: hs-tier1 - hs-tier5 > > PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into rwrapper.aarch64 - Merge branch 'master' into rwrapper.aarch64 - explicit constructors - Merge branch 'master' into rwrapper.aarch64 - 8292203: AArch64: Represent Registers as values - cleanups - x86: Register class wrappers ------------- Changes: https://git.openjdk.org/jdk/pull/9826/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9826&range=04 Stats: 527 lines in 15 files changed: 121 ins; 53 del; 353 mod Patch: https://git.openjdk.org/jdk/pull/9826.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9826/head:pull/9826 PR: https://git.openjdk.org/jdk/pull/9826 From duke at openjdk.org Wed Aug 24 05:16:31 2022 From: duke at openjdk.org (David Schlosnagle) Date: Wed, 24 Aug 2022 05:16:31 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 17:58:39 GMT, Jatin Bhateja wrote: > Hi, > > This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. > A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. > > Kindly review and share your feedback. > > Best Regards, > Jatin src/hotspot/share/utilities/moveBits.hpp line 31: > 29: #include "utilities/globalDefinitions.hpp" > 30: > 31: inline uint64_t bit_reverse(uint64_t x) { Should this still credit Hacker's Delight? Suggestion: inline uint64_t bit_reverse(uint64_t x) { // Hacker's Delight, Figure 7-1 src/hotspot/share/utilities/moveBits.hpp line 47: > 45: x = (x & 0x00FF00FF00FF00FFL) << 8 | (x & 0xFF00FF00FF00FF00L) >> 8; > 46: default: > 47: break; Should this assert not reachable? ------------- PR: https://git.openjdk.org/jdk/pull/9987 From kbarrett at openjdk.org Wed Aug 24 06:00:32 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 24 Aug 2022 06:00:32 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 17:58:39 GMT, Jatin Bhateja wrote: > Hi, > > This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. > A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. > > Kindly review and share your feedback. > > Best Regards, > Jatin Changes requested by kbarrett (Reviewer). src/hotspot/share/utilities/moveBits.hpp line 31: > 29: #include "utilities/globalDefinitions.hpp" > 30: > 31: inline uint64_t bit_reverse(uint64_t x) { >From the name I expect this function to reverse the bits in x, but it only reverses the bits in the individual bytes. Please give it a better name, like `reverse_bits_in_bytes`. src/hotspot/share/utilities/moveBits.hpp line 31: > 29: #include "utilities/globalDefinitions.hpp" > 30: > 31: inline uint64_t bit_reverse(uint64_t x) { Throughout, do we really want to always force extension to 64bit types on a 32bit platform? src/hotspot/share/utilities/moveBits.hpp line 31: > 29: #include "utilities/globalDefinitions.hpp" > 30: > 31: inline uint64_t bit_reverse(uint64_t x) { It's probably worth having comments referring to the corresponding Hacker's Delight sections for both of these functions. src/hotspot/share/utilities/moveBits.hpp line 32: > 30: > 31: inline uint64_t bit_reverse(uint64_t x) { > 32: x = (x & 0x5555555555555555L) << 1 | (x & 0xAAAAAAAAAAAAAAAAL) >> 1; Throughout, the `L` suffixes on the integer literals are unnecessary and potentially confusing. (Confusing because `L` doesn't mean `long`, which would actually be wrong on Windows.) We have `CONST64` and `UCONST64` macros in globalDefinitions.hpp that we generally use for 64bit integer literals. src/hotspot/share/utilities/moveBits.hpp line 38: > 36: } > 37: > 38: inline uint64_t byte_reverse(uint64_t x, uint8_t bw) { It's unclear whether this function is intended to be a public API provided by this file, or an implementation detail of reverse_bits. It seems like it could be the former, in which case it should be documented as such, and probably reordered with bit_reverse (which likely *is* intended to just be an implementation detail for reverse_bits), and renamed to reverse_bytes for consistency. src/hotspot/share/utilities/moveBits.hpp line 41: > 39: switch(bw) { > 40: case 64: > 41: x = (x & 0x00000000FFFFFFFFL) << 32 | (x & 0xFFFFFFFF00000000L) >> 32; Here's a case where the `L` suffix doesn't denote a 64 bit literal on Windows (because it is LLP64), though it doesn't matter because of the immediate implicit conversion with the type of `x`. src/hotspot/share/utilities/moveBits.hpp line 47: > 45: x = (x & 0x00FF00FF00FF00FFL) << 8 | (x & 0xFF00FF00FF00FF00L) >> 8; > 46: default: > 47: break; Rather than assuming the only uncovered case is 8, I think better would be to have an explicit case for 8 and a default ShouldNotReachHere case. src/hotspot/share/utilities/moveBits.hpp line 52: > 50: } > 51: > 52: template struct ReverseBitsImpl {}; There's no benefit to using uint8_t for the size. The type of the result of `sizeof` is `size_t` - just use that. src/hotspot/share/utilities/moveBits.hpp line 63: > 61: /***************************************************************************** > 62: * GCC and compatible (including Clang) > 63: *****************************************************************************/ Is it really worth the extra code to allow the use of the gcc builtins? src/hotspot/share/utilities/moveBits.hpp line 67: > 65: template struct ReverseBitsImpl { > 66: static T doit(T v) { > 67: uint64_t r = bit_reverse((uint64_t)v); Throughout, implicit conversion of integral types will deal with the argument to `bit_reverse`, so there's no need to cast the argument being passed to it. src/hotspot/share/utilities/moveBits.hpp line 114: > 112: // Performs bit reversal of a multi-byte type, we implement and support > 113: // variants for 8, 16, 32 and 64 bit integral types. > 114: template inline T reverse_bits(T v) { Restrict to integral types, using `ENABLE_IF(std::is_integral::value)`. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From chagedorn at openjdk.org Wed Aug 24 06:49:13 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 24 Aug 2022 06:49:13 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v15] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 08:07:52 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: >> >> Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> >> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. >> >> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): >> >> Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) >> >> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. >> >> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf >> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. >> >> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. >> >> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. >> >> **Testing:** >> Apart from manual testing, I've added two kinds of tests: >> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. >> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. >> >> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. >> >> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. >> >> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). >> >> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits: > > - Merge branch 'master' into JDK-8242181 > - Fix optimized build > - Merge branch 'master' into JDK-8242181 > - Merge branch 'master' into JDK-8242181 > - Exclude TestDwarf.java when run with product because TraceDwarf is a develop flag > - Merge branch 'master' into JDK-8242181 > - Merge branch 'master' into JDK-8242181 > - Fix TestDwarf for older GCC versions > - Change logging from UL to tty based with new TraceDwarfLevel develop flag > - Add support to parse the .debug_line section in DWARF 2 as emitted by GCC 8, add some comments > - ... and 62 more: https://git.openjdk.org/jdk/compare/d1edda8f...d4a4e873 Thanks everybody for your feedback, comments, and reviews! ------------- PR: https://git.openjdk.org/jdk/pull/7126 From chagedorn at openjdk.org Wed Aug 24 06:49:14 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 24 Aug 2022 06:49:14 GMT Subject: Integrated: 8242181: [Linux] Show source information when printing native stack traces in hs_err files In-Reply-To: References: Message-ID: <-9ObgxUtih69P3m96GAZGmEYuPbfgxJ6g6Uz-DEKXzU=.60165fe7-5b5d-474d-a298-d9f473e725ee@github.com> On Tue, 18 Jan 2022 13:19:39 GMT, Christian Hagedorn wrote: > When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: > > Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 > V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec > V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 > V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df > V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 > V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d > V [libjvm.so+0x12091c9] JavaThread::run()+0x167 > V [libjvm.so+0x1206ada] Thread::call_run()+0x180 > V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f > > This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. > > This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): > > Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) > V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) > V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) > V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) > V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) > V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) > V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) > V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) > V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) > > For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. > > The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf > I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. > > The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. > > Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. > > **Testing:** > Apart from manual testing, I've added two kinds of tests: > - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. > - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. > > On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. > > To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. > > I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). > > Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! > > Thanks, > Christian This pull request has now been integrated. Changeset: 13c03696 Author: Christian Hagedorn URL: https://git.openjdk.org/jdk/commit/13c03696463cb3ba77663edfd2dfb78d3f45cbaa Stats: 2781 lines in 18 files changed: 2686 ins; 41 del; 54 mod 8242181: [Linux] Show source information when printing native stack traces in hs_err files Reviewed-by: erikj, tschatzl, stuefe, ihse ------------- PR: https://git.openjdk.org/jdk/pull/7126 From eosterlund at openjdk.org Wed Aug 24 08:49:13 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 24 Aug 2022 08:49:13 GMT Subject: RFR: 8292194: G1 nmethod entry barrier disarm value wraps around too early In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 14:53:06 GMT, Erik ?sterlund wrote: > The disarm value for G1 nmethod entry barriers assumes that a concurrent GC can be aborted at most once. However, it can happen many times. In order to avoid ABA issues in the nmethod entry barriers, the limit for wrapping around and reusing numbers needs to be higher. This patch changes that point to INT_MAX as there is little point in using lower values. Any more takers? ------------- PR: https://git.openjdk.org/jdk/pull/9822 From eosterlund at openjdk.org Wed Aug 24 08:53:13 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 24 Aug 2022 08:53:13 GMT Subject: RFR: 8290025: Remove the Sweeper [v12] In-Reply-To: References: Message-ID: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Erik ?sterlund 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 8290025_remove_sweeper - Merge branch 'master' into 8290025_remove_sweeper - Trigger GC from adapter blob allocations - Zhengyu comments v1 - Redundant variable - Polish comment - Merge branch 'master' into 8290025_remove_sweeper - Removed more stale things - Remove incorrect comment - Feedback v2 - ... and 2 more: https://git.openjdk.org/jdk/compare/ad2e0c4d...21d4ccb5 ------------- Changes: https://git.openjdk.org/jdk/pull/9741/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=11 Stats: 4118 lines in 188 files changed: 560 ins; 2991 del; 567 mod Patch: https://git.openjdk.org/jdk/pull/9741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9741/head:pull/9741 PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Wed Aug 24 08:59:33 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 24 Aug 2022 08:59:33 GMT Subject: RFR: 8290025: Remove the Sweeper [v11] In-Reply-To: References: Message-ID: <_mtHwFy5gky3zaHy040IwGrjOXo9tnuTIxFk2Y7ft9w=.30af557f-1a8f-4773-b981-0a1b7b0dd778@github.com> On Tue, 23 Aug 2022 20:46:49 GMT, Martin Doerr wrote: > I haven't reviewed the whole PR (there were already enough reviews), but I like the sweeper removal and what I've seen looks good. Impressive how strongly the sweeper is interwoven with the rest of hotspot! I'll be glad to see it go away. > > Please note that there's a little more merging required after recent changes. > > I'd like to rerun it in our nightly testing and discuss with Thomas. Heuristics fine tuning could still be done as follow-up, but we should try to avoid major drawbacks. I fixed the merge conflict. Please let me know when you feel ready on your end. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From tschatzl at openjdk.org Wed Aug 24 10:08:24 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Aug 2022 10:08:24 GMT Subject: RFR: 8292194: G1 nmethod entry barrier disarm value wraps around too early In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 14:53:06 GMT, Erik ?sterlund wrote: > The disarm value for G1 nmethod entry barriers assumes that a concurrent GC can be aborted at most once. However, it can happen many times. In order to avoid ABA issues in the nmethod entry barriers, the limit for wrapping around and reusing numbers needs to be higher. This patch changes that point to INT_MAX as there is little point in using lower values. src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 113: > 111: // aborted N times, that is when there could be ABA problems. If there are anything > 112: // close to INT_MAX - 1 GCs starting without being able to finish, something is > 113: // seriously wrong. Unfortunately, "something is seriously wrong" is not true. I have seen benchmarks where G1 is stuck in Concurrent Undo cycles because the concurrent start gc always can always reclaim some humongous object that gets G1 below the concurrent marking threshold again. That can last for 100's of such occurrences. Obviously idk if before INT_MAX such concurrent undo marks there will be at least one "full" marking cycle, but there does not seem to be a guarantee. ------------- PR: https://git.openjdk.org/jdk/pull/9822 From duke at openjdk.org Wed Aug 24 10:56:40 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 24 Aug 2022 10:56:40 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way [v2] In-Reply-To: References: Message-ID: > This PR removes a lot of boilerplate that was required when creating multi-threaded tests and ports 2 tests to show that the number of lines of code is significantly reduced and that porting is fairly trivial. The ported tests also serve as an introduction to others who're looking into writing their own multi-threaded tests. > > Testing: Ran the ported tests on my machine, also running the tests on x64 {Windows, Linux, Mac OS X], aarch64 { Linux, Mac OS X} and tier1 for "completeness". Johan Sj?l?n has updated the pull request incrementally with four additional commits since the last revision: - Add some more comments - Fix S to int for BasicTestThread too - Remove S from TestThreadGroup and fix it to int for thread id - Make N a constructor argument instead of a template one ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9962/files - new: https://git.openjdk.org/jdk/pull/9962/files/bf1b5524..f36bdb0e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9962&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9962&range=00-01 Stats: 33 lines in 3 files changed: 6 ins; 5 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/9962.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9962/head:pull/9962 PR: https://git.openjdk.org/jdk/pull/9962 From duke at openjdk.org Wed Aug 24 11:01:18 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 24 Aug 2022 11:01:18 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way [v3] In-Reply-To: References: Message-ID: > This PR removes a lot of boilerplate that was required when creating multi-threaded tests and ports 2 tests to show that the number of lines of code is significantly reduced and that porting is fairly trivial. The ported tests also serve as an introduction to others who're looking into writing their own multi-threaded tests. > > Testing: Ran the ported tests on my machine, also running the tests on x64 {Windows, Linux, Mac OS X], aarch64 { Linux, Mac OS X} and tier1 for "completeness". Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Free array at end ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9962/files - new: https://git.openjdk.org/jdk/pull/9962/files/f36bdb0e..acb6ced6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9962&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9962&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9962.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9962/head:pull/9962 PR: https://git.openjdk.org/jdk/pull/9962 From duke at openjdk.org Wed Aug 24 11:01:20 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 24 Aug 2022 11:01:20 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way [v2] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 10:56:40 GMT, Johan Sj?l?n wrote: >> This PR removes a lot of boilerplate that was required when creating multi-threaded tests and ports 2 tests to show that the number of lines of code is significantly reduced and that porting is fairly trivial. The ported tests also serve as an introduction to others who're looking into writing their own multi-threaded tests. >> >> Testing: Ran the ported tests on my machine, also running the tests on x64 {Windows, Linux, Mac OS X], aarch64 { Linux, Mac OS X} and tier1 for "completeness". > > Johan Sj?l?n has updated the pull request incrementally with four additional commits since the last revision: > > - Add some more comments > - Fix S to int for BasicTestThread too > - Remove S from TestThreadGroup and fix it to int for thread id > - Make N a constructor argument instead of a template one Please review this version :-). ------------- PR: https://git.openjdk.org/jdk/pull/9962 From eosterlund at openjdk.org Wed Aug 24 11:08:28 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 24 Aug 2022 11:08:28 GMT Subject: RFR: 8292194: G1 nmethod entry barrier disarm value wraps around too early In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 10:04:47 GMT, Thomas Schatzl wrote: >> The disarm value for G1 nmethod entry barriers assumes that a concurrent GC can be aborted at most once. However, it can happen many times. In order to avoid ABA issues in the nmethod entry barriers, the limit for wrapping around and reusing numbers needs to be higher. This patch changes that point to INT_MAX as there is little point in using lower values. > > src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 113: > >> 111: // aborted N times, that is when there could be ABA problems. If there are anything >> 112: // close to INT_MAX - 1 GCs starting without being able to finish, something is >> 113: // seriously wrong. > > Unfortunately, "something is seriously wrong" is not true. I have seen benchmarks where G1 is stuck in Concurrent Undo cycles because the concurrent start gc always can always reclaim some humongous object that gets G1 below the concurrent marking threshold again. That can last for 100's of such occurrences. > Obviously idk if before INT_MAX such concurrent undo marks there will be at least one "full" marking cycle, but there does not seem to be a guarantee. > One solution is to force completion of a marking cycle after X (where X is a very high number) subsequent concurrent undos. Let's say a rather rapid back to back concurrent full GC interval might be 10 ms ish. With such time intervals, it would take a bit over 16 years worth of being constantly interrupted and not finishing a single GC cycle, before any assumption would be broken. I wouldn't wish for anyone to be stuck in a single JVM for that long, hence why I think "something is seriously wrong" if that ever happened. I'm personally okay with that, and think we have bigger fish to fry. For example, the CollectedHeap::_total_collections counter is an unsigned int and there assumptions that it never wraps around. That sounds more likely to ever happen. Yet seemingly unlikely. ------------- PR: https://git.openjdk.org/jdk/pull/9822 From duke at openjdk.org Wed Aug 24 11:25:02 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 24 Aug 2022 11:25:02 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way [v4] In-Reply-To: References: Message-ID: > This PR removes a lot of boilerplate that was required when creating multi-threaded tests and ports 2 tests to show that the number of lines of code is significantly reduced and that porting is fairly trivial. The ported tests also serve as an introduction to others who're looking into writing their own multi-threaded tests. > > Testing: Ran the ported tests on my machine, also running the tests on x64 {Windows, Linux, Mac OS X], aarch64 { Linux, Mac OS X} and tier1 for "completeness". Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Use symbol_name_length as char array size ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9962/files - new: https://git.openjdk.org/jdk/pull/9962/files/acb6ced6..f0cb7854 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9962&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9962&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9962.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9962/head:pull/9962 PR: https://git.openjdk.org/jdk/pull/9962 From rehn at openjdk.org Wed Aug 24 11:33:24 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 24 Aug 2022 11:33:24 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way [v4] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 11:25:02 GMT, Johan Sj?l?n wrote: >> This PR removes a lot of boilerplate that was required when creating multi-threaded tests and ports 2 tests to show that the number of lines of code is significantly reduced and that porting is fairly trivial. The ported tests also serve as an introduction to others who're looking into writing their own multi-threaded tests. >> >> Testing: Ran the ported tests on my machine, also running the tests on x64 {Windows, Linux, Mac OS X], aarch64 { Linux, Mac OS X} and tier1 for "completeness". > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Use symbol_name_length as char array size Still good, thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9962 From tschatzl at openjdk.org Wed Aug 24 11:35:26 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Aug 2022 11:35:26 GMT Subject: RFR: 8292194: G1 nmethod entry barrier disarm value wraps around too early In-Reply-To: References: Message-ID: <4Yil4ygBBV2FLcazKWrqO7CYmYVHhDYRTCMMuQMS5sE=.1246eebc-76c8-4f35-9090-ee84de7713dc@github.com> On Wed, 10 Aug 2022 14:53:06 GMT, Erik ?sterlund wrote: > The disarm value for G1 nmethod entry barriers assumes that a concurrent GC can be aborted at most once. However, it can happen many times. In order to avoid ABA issues in the nmethod entry barriers, the limit for wrapping around and reusing numbers needs to be higher. This patch changes that point to INT_MAX as there is little point in using lower values. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9822 From tschatzl at openjdk.org Wed Aug 24 11:35:28 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Aug 2022 11:35:28 GMT Subject: RFR: 8292194: G1 nmethod entry barrier disarm value wraps around too early In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 11:06:19 GMT, Erik ?sterlund wrote: >> src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 113: >> >>> 111: // aborted N times, that is when there could be ABA problems. If there are anything >>> 112: // close to INT_MAX - 1 GCs starting without being able to finish, something is >>> 113: // seriously wrong. >> >> Unfortunately, "something is seriously wrong" is not true. I have seen benchmarks where G1 is stuck in Concurrent Undo cycles because the concurrent start gc always can always reclaim some humongous object that gets G1 below the concurrent marking threshold again. That can last for 100's of such occurrences. >> Obviously idk if before INT_MAX such concurrent undo marks there will be at least one "full" marking cycle, but there does not seem to be a guarantee. >> One solution is to force completion of a marking cycle after X (where X is a very high number) subsequent concurrent undos. > > Let's say a rather rapid back to back concurrent full GC interval might be 10 ms ish. With such time intervals, it would take a bit over 16 years worth of being constantly interrupted and not finishing a single GC cycle, before any assumption would be broken. I wouldn't wish for anyone to be stuck in a single JVM for that long, hence why I think "something is seriously wrong" if that ever happened. I'm personally okay with that, and think we have bigger fish to fry. For example, the CollectedHeap::_total_collections counter is an unsigned int and there assumptions that it never wraps around. That sounds more likely to ever happen. Yet seemingly unlikely. :rofl: Just mentioning. Lgtm. ------------- PR: https://git.openjdk.org/jdk/pull/9822 From stuefe at openjdk.org Wed Aug 24 11:55:40 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Aug 2022 11:55:40 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way [v4] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 11:25:02 GMT, Johan Sj?l?n wrote: >> This PR removes a lot of boilerplate that was required when creating multi-threaded tests and ports 2 tests to show that the number of lines of code is significantly reduced and that porting is fairly trivial. The ported tests also serve as an introduction to others who're looking into writing their own multi-threaded tests. >> >> Testing: Ran the ported tests on my machine, also running the tests on x64 {Windows, Linux, Mac OS X], aarch64 { Linux, Mac OS X} and tier1 for "completeness". > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Use symbol_name_length as char array size LGTM. Thanks for making N a runtime parameter. ..Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/9962 From roland at openjdk.org Wed Aug 24 13:10:16 2022 From: roland at openjdk.org (Roland Westrelin) Date: Wed, 24 Aug 2022 13:10:16 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 09:33:58 GMT, Pengfei Li wrote: > Recently, an igvn infinite loop issue was reported. Git bisection shows > it appears after our JDK-8289996 patch. But after that patch is backed > out, we find similar test still fails. We have attached a jtreg case to > reproduce this issue. > > The ideal graph of the problematic method has a `MulINode` multiplying a > `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` > moves the constant input to the right hand side. And `Ideal()` function > in its parent class `MulNode` has the similar logic. In some code paths, > `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, > `MulINode` and `MulNode` use different ways to check constant. One calls > `type->singleton()` and the other calls `node->find_int_con(val)` which > accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` > can be evaluated to a constant, the two inputs of the `MulNode` will be > swapped back and forth in `Ideal()` calls. It eventually causes the igvn > infinite loop issue. > > This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` > because it's enough to do this by calling `MulNode::Ideal()`. We also do > some code cleanup in this patch as we have done in JDK-8289996. > > Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. src/hotspot/share/opto/mulnode.cpp line 252: > 250: > 251: // Now we have a constant Node on the right and the constant in con > 252: if (con == 0) return NULL; // By zero is handled by Value call Value() runs after Ideal so why wouldn't we have con == 0 here? ------------- PR: https://git.openjdk.org/jdk/pull/9820 From eosterlund at openjdk.org Wed Aug 24 13:11:27 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 24 Aug 2022 13:11:27 GMT Subject: RFR: 8292194: G1 nmethod entry barrier disarm value wraps around too early In-Reply-To: References: Message-ID: <5NXpcYJIjv45mZVLHm3d6f_amsIlklANuBI0gGVx51M=.3c7f9a9e-437d-4c3a-af32-f2856799dfc3@github.com> On Wed, 24 Aug 2022 11:31:33 GMT, Thomas Schatzl wrote: >> Let's say a rather rapid back to back concurrent full GC interval might be 10 ms ish. With such time intervals, it would take a bit over 16 years worth of being constantly interrupted and not finishing a single GC cycle, before any assumption would be broken. I wouldn't wish for anyone to be stuck in a single JVM for that long, hence why I think "something is seriously wrong" if that ever happened. I'm personally okay with that, and think we have bigger fish to fry. For example, the CollectedHeap::_total_collections counter is an unsigned int and there assumptions that it never wraps around. That sounds more likely to ever happen. Yet seemingly unlikely. > > :rofl: > Just mentioning. Lgtm. Thanks for the review, @tschatzl. ------------- PR: https://git.openjdk.org/jdk/pull/9822 From eosterlund at openjdk.org Wed Aug 24 13:15:19 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 24 Aug 2022 13:15:19 GMT Subject: Integrated: 8292194: G1 nmethod entry barrier disarm value wraps around too early In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 14:53:06 GMT, Erik ?sterlund wrote: > The disarm value for G1 nmethod entry barriers assumes that a concurrent GC can be aborted at most once. However, it can happen many times. In order to avoid ABA issues in the nmethod entry barriers, the limit for wrapping around and reusing numbers needs to be higher. This patch changes that point to INT_MAX as there is little point in using lower values. This pull request has now been integrated. Changeset: a45a4b94 Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/a45a4b9465d7d01715425000c4fd47c0aa3e76ca Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod 8292194: G1 nmethod entry barrier disarm value wraps around too early Reviewed-by: ayang, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/9822 From coleenp at openjdk.org Wed Aug 24 13:23:05 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Aug 2022 13:23:05 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v3] In-Reply-To: References: Message-ID: > This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. > > Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. > I added a test for printing dictionary statistics. > > This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. Coleen Phillimore 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 cht-dictionary - Conditionalize scanning function call for safepoint. - Use ConcurrentHashtable for Dictionary ------------- Changes: https://git.openjdk.org/jdk/pull/9886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9886&range=02 Stats: 612 lines in 29 files changed: 259 ins; 181 del; 172 mod Patch: https://git.openjdk.org/jdk/pull/9886.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9886/head:pull/9886 PR: https://git.openjdk.org/jdk/pull/9886 From stefank at openjdk.org Wed Aug 24 13:42:27 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 24 Aug 2022 13:42:27 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory Message-ID: HotSpot performs "critical metaspace allocations" when it's running out of metaspace. The failed allocations are registered in a queue, which the GC prioritizes when cleaning up the metaspace. There's a race in the code that handles these requests. These requests are added to the queue, and the GC will "process" each request in turn when it runs the metaspace purge phase. The queue handling has an optimization that says that only the first request in the queue needs to trigger the GC, all subsequent requests in the queue will wait for that GC. When the GC gets to the purge phase it will mark in all requests that they have been processed. Note: that this doesn't mean that the request was satisfied, it could be that the result was NULL (and the thread will trigger a last-effort GC before it throws an OOME). The bug is in the code that determines if a request is responsible for triggering a new GC. The current code just checks if the current request is first in the queue. This doesn't work if the code is called just after the GC has run purge, but before the old requests have been removed. The new request sees that there are already elements in the queue, so it doesn't trigger the GC. And at the same time, the old requests have been processed and they won't trigger the GC either. So, now the new request is waiting for a GC that will not be triggered by anyone. Note: The reason why there's a delay between the GC processing a request, and the removal from the queue, is that the Java thread that added the request is also responsible for removing the request form the queue. The reason for this is that the mentioned last-effort GC, needs to be able to process the request a second time. The fix-proposal is to let threads adding new requests check if the added request is the first *non-processed* request in the queue. If it is, that request/thread is responsible for triggering the GC for itself, and any subsequently added requests (until the GC runs the next round of request processing). However, there's a snatch to this proposal. The request processing is done inside `Metaspace::purge()`, and that function is skipped if the GC didn't unload any classes. The proposed logic relies on that function to always be run when a GC is running. So, I've also changed so that the GC unconditionally calls the request processing. An alternative would be to always run the Metaspace::purge() code. That might even help return memory from temporarily allocated metaspace memory earlier, but I've left that exercise for a potential future improvement. I've also tweaked the test so that we get a bit more info if this test fails again. Testing: I could reliably reproduce the original hang on my macbook laptop, within a few minutes. With this fix I can run the test in a loop for hours without reproducing the hang. I've tested this together with Generational ZGC code, running tier1-tier7 on Linux x64. I've started more extensive testing on openjdk/jdk. ------------- Commit messages: - Trailiing whitespaces - Remove deceiving Xlog line - 8292697: ZGC: Hangs when almost out of metaspace memory Changes: https://git.openjdk.org/jdk/pull/9985/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9985&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292697 Stats: 84 lines in 7 files changed: 51 ins; 5 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/9985.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9985/head:pull/9985 PR: https://git.openjdk.org/jdk/pull/9985 From eosterlund at openjdk.org Wed Aug 24 13:42:28 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 24 Aug 2022 13:42:28 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 15:56:54 GMT, Stefan Karlsson wrote: > HotSpot performs "critical metaspace allocations" when it's running out of metaspace. The failed allocations are registered in a queue, which the GC prioritizes when cleaning up the metaspace. There's a race in the code that handles these requests. > > These requests are added to the queue, and the GC will "process" each request in turn when it runs the metaspace purge phase. The queue handling has an optimization that says that only the first request in the queue needs to trigger the GC, all subsequent requests in the queue will wait for that GC. When the GC gets to the purge phase it will mark in all requests that they have been processed. Note: that this doesn't mean that the request was satisfied, it could be that the result was NULL (and the thread will trigger a last-effort GC before it throws an OOME). > > The bug is in the code that determines if a request is responsible for triggering a new GC. The current code just checks if the current request is first in the queue. This doesn't work if the code is called just after the GC has run purge, but before the old requests have been removed. The new request sees that there are already elements in the queue, so it doesn't trigger the GC. And at the same time, the old requests have been processed and they won't trigger the GC either. So, now the new request is waiting for a GC that will not be triggered by anyone. > > Note: The reason why there's a delay between the GC processing a request, and the removal from the queue, is that the Java thread that added the request is also responsible for removing the request form the queue. The reason for this is that the mentioned last-effort GC, needs to be able to process the request a second time. > > The fix-proposal is to let threads adding new requests check if the added request is the first *non-processed* request in the queue. If it is, that request/thread is responsible for triggering the GC for itself, and any subsequently added requests (until the GC runs the next round of request processing). > > However, there's a snatch to this proposal. The request processing is done inside `Metaspace::purge()`, and that function is skipped if the GC didn't unload any classes. The proposed logic relies on that function to always be run when a GC is running. So, I've also changed so that the GC unconditionally calls the request processing. An alternative would be to always run the Metaspace::purge() code. That might even help return memory from temporarily allocated metaspace memory earlier, but I've left that exercise for a potential future improvement. > > I've also tweaked the test so that we get a bit more info if this test fails again. > > Testing: I could reliably reproduce the original hang on my macbook laptop, within a few minutes. With this fix I can run the test in a loop for hours without reproducing the hang. I've tested this together with Generational ZGC code, running tier1-tier7 on Linux x64. I've started more extensive testing on openjdk/jdk. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/9985 From stefank at openjdk.org Wed Aug 24 13:42:28 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 24 Aug 2022 13:42:28 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 15:56:54 GMT, Stefan Karlsson wrote: > HotSpot performs "critical metaspace allocations" when it's running out of metaspace. The failed allocations are registered in a queue, which the GC prioritizes when cleaning up the metaspace. There's a race in the code that handles these requests. > > These requests are added to the queue, and the GC will "process" each request in turn when it runs the metaspace purge phase. The queue handling has an optimization that says that only the first request in the queue needs to trigger the GC, all subsequent requests in the queue will wait for that GC. When the GC gets to the purge phase it will mark in all requests that they have been processed. Note: that this doesn't mean that the request was satisfied, it could be that the result was NULL (and the thread will trigger a last-effort GC before it throws an OOME). > > The bug is in the code that determines if a request is responsible for triggering a new GC. The current code just checks if the current request is first in the queue. This doesn't work if the code is called just after the GC has run purge, but before the old requests have been removed. The new request sees that there are already elements in the queue, so it doesn't trigger the GC. And at the same time, the old requests have been processed and they won't trigger the GC either. So, now the new request is waiting for a GC that will not be triggered by anyone. > > Note: The reason why there's a delay between the GC processing a request, and the removal from the queue, is that the Java thread that added the request is also responsible for removing the request form the queue. The reason for this is that the mentioned last-effort GC, needs to be able to process the request a second time. > > The fix-proposal is to let threads adding new requests check if the added request is the first *non-processed* request in the queue. If it is, that request/thread is responsible for triggering the GC for itself, and any subsequently added requests (until the GC runs the next round of request processing). > > However, there's a snatch to this proposal. The request processing is done inside `Metaspace::purge()`, and that function is skipped if the GC didn't unload any classes. The proposed logic relies on that function to always be run when a GC is running. So, I've also changed so that the GC unconditionally calls the request processing. An alternative would be to always run the Metaspace::purge() code. That might even help return memory from temporarily allocated metaspace memory earlier, but I've left that exercise for a potential future improvement. > > I've also tweaked the test so that we get a bit more info if this test fails again. > > Testing: I could reliably reproduce the original hang on my macbook laptop, within a few minutes. With this fix I can run the test in a loop for hours without reproducing the hang. I've tested this together with Generational ZGC code, running tier1-tier7 on Linux x64. I've started more extensive testing on openjdk/jdk. Thanks Erik! ------------- PR: https://git.openjdk.org/jdk/pull/9985 From duke at openjdk.org Wed Aug 24 14:23:49 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 24 Aug 2022 14:23:49 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v3] In-Reply-To: References: Message-ID: > May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? > > This PR does 3 things: > > * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot > * Adds some new utilities for writing multi-threaded tests. > * Adds some tests for MRSW Mutex using these new utilities > > The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 > > [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: - Update documentation - Fix outdated headers and remove dead code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9838/files - new: https://git.openjdk.org/jdk/pull/9838/files/e842c508..d659314d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9838&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9838&range=01-02 Stats: 23 lines in 1 file changed: 10 ins; 5 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9838.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9838/head:pull/9838 PR: https://git.openjdk.org/jdk/pull/9838 From mdoerr at openjdk.org Wed Aug 24 14:25:47 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 24 Aug 2022 14:25:47 GMT Subject: RFR: 8290025: Remove the Sweeper [v12] In-Reply-To: References: Message-ID: <_co2QqWAO4E85o08JWqIdbIfHIZvuzzd8HqVQQ7S1ZM=.6843dfe1-5088-4c9c-a2c8-0370d90463bb@github.com> On Wed, 24 Aug 2022 08:53:13 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund 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 8290025_remove_sweeper > - Merge branch 'master' into 8290025_remove_sweeper > - Trigger GC from adapter blob allocations > - Zhengyu comments v1 > - Redundant variable > - Polish comment > - Merge branch 'master' into 8290025_remove_sweeper > - Removed more stale things > - Remove incorrect comment > - Feedback v2 > - ... and 2 more: https://git.openjdk.org/jdk/compare/ad2e0c4d...21d4ccb5 I think the term "full GC" has led to some confusion. You mean that we now need a complete marking cycle before we can flush any unused nmethods, right? People often think about terrible stop-the-world GCs which tidy up the whole Java heap etc. when reading "full GC". ------------- PR: https://git.openjdk.org/jdk/pull/9741 From coleenp at openjdk.org Wed Aug 24 14:30:14 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Aug 2022 14:30:14 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v4] In-Reply-To: References: Message-ID: <7XwTJ9eW-Nz1XEiQZiTS7e7RNOmKZvc9JozLI7VIlrk=.a19864dd-66a1-4515-9287-fac0d3292591@github.com> > This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. > > Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. > I added a test for printing dictionary statistics. > > This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. Coleen Phillimore 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 cht-dictionary - Conditionalize scanning function call for safepoint. - Use ConcurrentHashtable for Dictionary ------------- Changes: https://git.openjdk.org/jdk/pull/9886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9886&range=03 Stats: 613 lines in 29 files changed: 260 ins; 181 del; 172 mod Patch: https://git.openjdk.org/jdk/pull/9886.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9886/head:pull/9886 PR: https://git.openjdk.org/jdk/pull/9886 From eosterlund at openjdk.org Wed Aug 24 14:51:34 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 24 Aug 2022 14:51:34 GMT Subject: RFR: 8290025: Remove the Sweeper [v12] In-Reply-To: <_co2QqWAO4E85o08JWqIdbIfHIZvuzzd8HqVQQ7S1ZM=.6843dfe1-5088-4c9c-a2c8-0370d90463bb@github.com> References: <_co2QqWAO4E85o08JWqIdbIfHIZvuzzd8HqVQQ7S1ZM=.6843dfe1-5088-4c9c-a2c8-0370d90463bb@github.com> Message-ID: On Wed, 24 Aug 2022 14:21:57 GMT, Martin Doerr wrote: > I think the term "full GC" has led to some confusion. You mean that we now need a complete marking cycle before we can flush any unused nmethods, right? > > People often think about terrible stop-the-world GCs which tidy up the whole Java heap etc. when reading "full GC". Yes that's right. By "full GC", I meant a GC that traverses live objects in the entire heap, as opposed to a subset of it. For me, whether that operation is performed STW, or concurrently doesn't make it more or less "full". But I realize that many people associate the term with a full [implied STW] GC. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From coleenp at openjdk.org Wed Aug 24 15:07:39 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Aug 2022 15:07:39 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 15:56:54 GMT, Stefan Karlsson wrote: > HotSpot performs "critical metaspace allocations" when it's running out of metaspace. The failed allocations are registered in a queue, which the GC prioritizes when cleaning up the metaspace. There's a race in the code that handles these requests. > > These requests are added to the queue, and the GC will "process" each request in turn when it runs the metaspace purge phase. The queue handling has an optimization that says that only the first request in the queue needs to trigger the GC, all subsequent requests in the queue will wait for that GC. When the GC gets to the purge phase it will mark in all requests that they have been processed. Note: that this doesn't mean that the request was satisfied, it could be that the result was NULL (and the thread will trigger a last-effort GC before it throws an OOME). > > The bug is in the code that determines if a request is responsible for triggering a new GC. The current code just checks if the current request is first in the queue. This doesn't work if the code is called just after the GC has run purge, but before the old requests have been removed. The new request sees that there are already elements in the queue, so it doesn't trigger the GC. And at the same time, the old requests have been processed and they won't trigger the GC either. So, now the new request is waiting for a GC that will not be triggered by anyone. > > Note: The reason why there's a delay between the GC processing a request, and the removal from the queue, is that the Java thread that added the request is also responsible for removing the request form the queue. The reason for this is that the mentioned last-effort GC, needs to be able to process the request a second time. > > The fix-proposal is to let threads adding new requests check if the added request is the first *non-processed* request in the queue. If it is, that request/thread is responsible for triggering the GC for itself, and any subsequently added requests (until the GC runs the next round of request processing). > > However, there's a snatch to this proposal. The request processing is done inside `Metaspace::purge()`, and that function is skipped if the GC didn't unload any classes. The proposed logic relies on that function to always be run when a GC is running. So, I've also changed so that the GC unconditionally calls the request processing. An alternative would be to always run the Metaspace::purge() code. That might even help return memory from temporarily allocated metaspace memory earlier, but I've left that exercise for a potential future improvement. > > I've also tweaked the test so that we get a bit more info if this test fails again. > > Testing: I could reliably reproduce the original hang on my macbook laptop, within a few minutes. With this fix I can run the test in a loop for hours without reproducing the hang. I've tested this together with Generational ZGC code, running tier1-tier7 on Linux x64. I've started more extensive testing on openjdk/jdk. This seems ok. The comments help describe this unexpected interaction. src/hotspot/share/memory/metaspaceCriticalAllocation.cpp line 152: > 150: if (is_first_unprocessed()) { > 151: // The first non-processed request takes ownership of triggering the GC > 152: // on behalf of itself, and all trailing requests in the list. why is this a lambda? why can't it just be code? test/hotspot/jtreg/vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java line 148: > 146: // it should be impossible > 147: try { > 148: log("just a tiny mint"); huh? ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/9985 From duke at openjdk.org Wed Aug 24 15:19:37 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 24 Aug 2022 15:19:37 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot In-Reply-To: References: Message-ID: <9pe5mQp6Yq78Esb63r9RFnWg-zanP5sE8jEzSpjH2zo=.19f0cda3-2805-4971-a2aa-afb5843944ef@github.com> On Wed, 17 Aug 2022 13:14:34 GMT, David Holmes wrote: >>> > Multi-Reader Single-Writer mutex >>> >>> Sorry to bikeshed but such a thing is called a ReadWriteLock or a ReadersWriterLock or something similar - can we please use familiar nomenclature here (even rwlock as per POSIX). "mutex" is a contraction of mutual-exclusion and as readers are not mutually exclusive it is an oxymoron to talk about a "multi-reader mutex". Thanks. >> >> For what it's worth, C++ Standard Library uses "mutex" to refer to an object >> that gets locked, and uses "lock" to refer to an RAII object that locks a >> "mutex". So it has, for example, `std::shared_mutex`, which is >> multi-reader/single-writer. The idea being that a "mutex" provides some kind >> of mutual exclusion - in the case of shared_mutex readers (multiple) are >> excluded from any writer, and writers are exclusive from each other. I'd >> prefer that to calling these new things "locks". > >> For what it's worth, C++ Standard Library uses "mutex" to refer to an object that gets locked, and uses "lock" to refer to an RAII object that locks a "mutex". > > So their "lock" would be our MutexLocker? The far more dominant terminology is that a mutex is a lock. Thank you for the additional review, @dholmes-ora . I fixed those and added some more documentation. The changes to `threadHelper.inline.hpp` is being merged through a separate patch (see JDK-8292679, https://github.com/openjdk/jdk/pull/9962), and so are not in need of review. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From stefank at openjdk.org Wed Aug 24 15:20:35 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 24 Aug 2022 15:20:35 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 14:47:35 GMT, Coleen Phillimore wrote: >> HotSpot performs "critical metaspace allocations" when it's running out of metaspace. The failed allocations are registered in a queue, which the GC prioritizes when cleaning up the metaspace. There's a race in the code that handles these requests. >> >> These requests are added to the queue, and the GC will "process" each request in turn when it runs the metaspace purge phase. The queue handling has an optimization that says that only the first request in the queue needs to trigger the GC, all subsequent requests in the queue will wait for that GC. When the GC gets to the purge phase it will mark in all requests that they have been processed. Note: that this doesn't mean that the request was satisfied, it could be that the result was NULL (and the thread will trigger a last-effort GC before it throws an OOME). >> >> The bug is in the code that determines if a request is responsible for triggering a new GC. The current code just checks if the current request is first in the queue. This doesn't work if the code is called just after the GC has run purge, but before the old requests have been removed. The new request sees that there are already elements in the queue, so it doesn't trigger the GC. And at the same time, the old requests have been processed and they won't trigger the GC either. So, now the new request is waiting for a GC that will not be triggered by anyone. >> >> Note: The reason why there's a delay between the GC processing a request, and the removal from the queue, is that the Java thread that added the request is also responsible for removing the request form the queue. The reason for this is that the mentioned last-effort GC, needs to be able to process the request a second time. >> >> The fix-proposal is to let threads adding new requests check if the added request is the first *non-processed* request in the queue. If it is, that request/thread is responsible for triggering the GC for itself, and any subsequently added requests (until the GC runs the next round of request processing). >> >> However, there's a snatch to this proposal. The request processing is done inside `Metaspace::purge()`, and that function is skipped if the GC didn't unload any classes. The proposed logic relies on that function to always be run when a GC is running. So, I've also changed so that the GC unconditionally calls the request processing. An alternative would be to always run the Metaspace::purge() code. That might even help return memory from temporarily allocated metaspace memory earlier, but I've left that exercise for a potential future improvement. >> >> I've also tweaked the test so that we get a bit more info if this test fails again. >> >> Testing: I could reliably reproduce the original hang on my macbook laptop, within a few minutes. With this fix I can run the test in a loop for hours without reproducing the hang. I've tested this together with Generational ZGC code, running tier1-tier7 on Linux x64. I've started more extensive testing on openjdk/jdk. > > src/hotspot/share/memory/metaspaceCriticalAllocation.cpp line 152: > >> 150: if (is_first_unprocessed()) { >> 151: // The first non-processed request takes ownership of triggering the GC >> 152: // on behalf of itself, and all trailing requests in the list. > > why is this a lambda? why can't it just be code? Just style: 1) I wanted to pull this logic out to a function/lambda 2) I wanted to keep the code near its usage 3) I didn't want all ceremony of having to declare the function / or creating a free function taking two extra parameters. > test/hotspot/jtreg/vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java line 148: > >> 146: // it should be impossible >> 147: try { >> 148: log("just a tiny mint"); > > huh? I wanted extra logging to see if we reached this statement (we didn't). And I though this line fitted the context, similar to the other rather silly statements in the test (eatALittleMemory, "washing hands before meal"). I can change it if it bothers you. ------------- PR: https://git.openjdk.org/jdk/pull/9985 From coleenp at openjdk.org Wed Aug 24 15:36:22 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Aug 2022 15:36:22 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 15:18:03 GMT, Stefan Karlsson wrote: >> src/hotspot/share/memory/metaspaceCriticalAllocation.cpp line 152: >> >>> 150: if (is_first_unprocessed()) { >>> 151: // The first non-processed request takes ownership of triggering the GC >>> 152: // on behalf of itself, and all trailing requests in the list. >> >> why is this a lambda? why can't it just be code? > > Just style: > 1) I wanted to pull this logic out to a function/lambda > 2) I wanted to keep the code near its usage > 3) I didn't want all ceremony of having to declare the function / or creating a free function taking two extra parameters. why did it need to be pulled out into a function? It's just a small amount of code that either is a lambda inline or just code inline? I'm a massive fan of lambdas but I don't see the purpose here. >> test/hotspot/jtreg/vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java line 148: >> >>> 146: // it should be impossible >>> 147: try { >>> 148: log("just a tiny mint"); >> >> huh? > > I wanted extra logging to see if we reached this statement (we didn't). And I though this line fitted the context, similar to the other rather silly statements in the test (eatALittleMemory, "washing hands before meal"). I can change it if it bothers you. nah, it's fine. ------------- PR: https://git.openjdk.org/jdk/pull/9985 From duke at openjdk.org Wed Aug 24 15:46:39 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 24 Aug 2022 15:46:39 GMT Subject: RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way [v4] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 11:25:02 GMT, Johan Sj?l?n wrote: >> This PR removes a lot of boilerplate that was required when creating multi-threaded tests and ports 2 tests to show that the number of lines of code is significantly reduced and that porting is fairly trivial. The ported tests also serve as an introduction to others who're looking into writing their own multi-threaded tests. >> >> Testing: Ran the ported tests on my machine, also running the tests on x64 {Windows, Linux, Mac OS X], aarch64 { Linux, Mac OS X} and tier1 for "completeness". > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Use symbol_name_length as char array size Thank you for the reviews and useful feedback, it's much appreciated! ------------- PR: https://git.openjdk.org/jdk/pull/9962 From dcubed at openjdk.org Wed Aug 24 15:48:37 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 24 Aug 2022 15:48:37 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 15:32:54 GMT, Coleen Phillimore wrote: >> I wanted extra logging to see if we reached this statement (we didn't). And I though this line fitted the context, similar to the other rather silly statements in the test (eatALittleMemory, "washing hands before meal"). I can change it if it bothers you. > > nah, it's fine. s/just a tiny mint/just a wafer thin mint/ https://en.wikipedia.org/wiki/Mr_Creosote ------------- PR: https://git.openjdk.org/jdk/pull/9985 From dcubed at openjdk.org Wed Aug 24 15:48:37 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 24 Aug 2022 15:48:37 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 15:44:29 GMT, Daniel D. Daugherty wrote: >> nah, it's fine. > > s/just a tiny mint/just a wafer thin mint/ > > https://en.wikipedia.org/wiki/Mr_Creosote Thanks for the laugh for my day!! ------------- PR: https://git.openjdk.org/jdk/pull/9985 From duke at openjdk.org Wed Aug 24 15:54:39 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 24 Aug 2022 15:54:39 GMT Subject: Integrated: 8292679: Simplify thread creation in gtest and port 2 tests to new way In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 10:53:27 GMT, Johan Sj?l?n wrote: > This PR removes a lot of boilerplate that was required when creating multi-threaded tests and ports 2 tests to show that the number of lines of code is significantly reduced and that porting is fairly trivial. The ported tests also serve as an introduction to others who're looking into writing their own multi-threaded tests. > > Testing: Ran the ported tests on my machine, also running the tests on x64 {Windows, Linux, Mac OS X], aarch64 { Linux, Mac OS X} and tier1 for "completeness". This pull request has now been integrated. Changeset: 69448f9c Author: Johan Sj?l?n Committer: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/69448f9c1a9b123be8ef63bb039111a8976a8da6 Stats: 204 lines in 3 files changed: 85 ins; 75 del; 44 mod 8292679: Simplify thread creation in gtest and port 2 tests to new way Reviewed-by: rehn, coleenp, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/9962 From stefank at openjdk.org Wed Aug 24 16:08:25 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 24 Aug 2022 16:08:25 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory In-Reply-To: References: Message-ID: <4_BdpmkZPlqQz8HLw65TSa5afYtVRTR33e8Zy8dXs6U=.354d3653-29d4-46d1-889f-c06f9f27e643@github.com> On Wed, 24 Aug 2022 15:32:46 GMT, Coleen Phillimore wrote: >> Just style: >> 1) I wanted to pull this logic out to a function/lambda >> 2) I wanted to keep the code near its usage >> 3) I didn't want all ceremony of having to declare the function / or creating a free function taking two extra parameters. > > why did it need to be pulled out into a function? It's just a small amount of code that either is a lambda inline or just code inline? I'm a massive fan of lambdas but I don't see the purpose here. I think code gets easier to read if you separate out the two concerns: 1) What is it you want to check 2) What is it you want to do if that happens I find that stye of code easier to read, and easier to add precise comments to. ------------- PR: https://git.openjdk.org/jdk/pull/9985 From stefank at openjdk.org Wed Aug 24 16:08:26 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 24 Aug 2022 16:08:26 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 15:44:58 GMT, Daniel D. Daugherty wrote: >> s/just a tiny mint/just a wafer thin mint/ >> >> https://en.wikipedia.org/wiki/Mr_Creosote > > Thanks for the laugh for my day!! Yeah, I should have looked up the exact quote. :) ------------- PR: https://git.openjdk.org/jdk/pull/9985 From coleenp at openjdk.org Wed Aug 24 16:18:27 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Aug 2022 16:18:27 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory In-Reply-To: <4_BdpmkZPlqQz8HLw65TSa5afYtVRTR33e8Zy8dXs6U=.354d3653-29d4-46d1-889f-c06f9f27e643@github.com> References: <4_BdpmkZPlqQz8HLw65TSa5afYtVRTR33e8Zy8dXs6U=.354d3653-29d4-46d1-889f-c06f9f27e643@github.com> Message-ID: On Wed, 24 Aug 2022 16:05:13 GMT, Stefan Karlsson wrote: >> why did it need to be pulled out into a function? It's just a small amount of code that either is a lambda inline or just code inline? I'm a massive fan of lambdas but I don't see the purpose here. > > I think code gets easier to read if you separate out the two concerns: > 1) What is it you want to check > 2) What is it you want to do if that happens > > I find that stye of code easier to read, and easier to add precise comments to. ? Fine, it's a matter of taste then. ------------- PR: https://git.openjdk.org/jdk/pull/9985 From duke at openjdk.org Wed Aug 24 16:27:35 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 24 Aug 2022 16:27:35 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v4] In-Reply-To: <7XwTJ9eW-Nz1XEiQZiTS7e7RNOmKZvc9JozLI7VIlrk=.a19864dd-66a1-4515-9287-fac0d3292591@github.com> References: <7XwTJ9eW-Nz1XEiQZiTS7e7RNOmKZvc9JozLI7VIlrk=.a19864dd-66a1-4515-9287-fac0d3292591@github.com> Message-ID: On Wed, 24 Aug 2022 14:30:14 GMT, Coleen Phillimore wrote: >> This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. >> >> Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. >> I added a test for printing dictionary statistics. >> >> This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. > > Coleen Phillimore 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 cht-dictionary > - Conditionalize scanning function call for safepoint. > - Use ConcurrentHashtable for Dictionary src/hotspot/share/classfile/dictionary.cpp line 411: > 409: // During class loading we may have cached a protection domain that has > 410: // since been unreferenced, so this entry should be cleared. > 411: void Dictionary::clean_cached_protection_domains(GrowableArray* delete_list) { Only mention of `GrowableArray` is here and it's a pointer, so do we really need to include the `growableArray.hpp` header? A forward declaration should be sufficient. Not entirely sure, maybe the templates screw it up. src/hotspot/share/classfile/dictionary.cpp line 412: > 410: // since been unreferenced, so this entry should be cleared. > 411: void Dictionary::clean_cached_protection_domains(GrowableArray* delete_list) { > 412: assert(JavaThread::current()->is_Java_thread(), "only called by JavaThread"); `JavaThread::current` already does this check, so just leave it as `Thread::current()`. Edit, to be clear: JavaThread::current() will fail its assertion before `->is_Java_thread()` is ever called on this line. src/hotspot/share/classfile/dictionary.hpp line 49: > 47: class Config { > 48: public: > 49: typedef DictionaryEntry* Value; Nit: Is there a reason that we're mixing `using` and `typedef` (see line 55)? ------------- PR: https://git.openjdk.org/jdk/pull/9886 From rehn at openjdk.org Wed Aug 24 17:43:43 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 24 Aug 2022 17:43:43 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v4] In-Reply-To: <7XwTJ9eW-Nz1XEiQZiTS7e7RNOmKZvc9JozLI7VIlrk=.a19864dd-66a1-4515-9287-fac0d3292591@github.com> References: <7XwTJ9eW-Nz1XEiQZiTS7e7RNOmKZvc9JozLI7VIlrk=.a19864dd-66a1-4515-9287-fac0d3292591@github.com> Message-ID: On Wed, 24 Aug 2022 14:30:14 GMT, Coleen Phillimore wrote: >> This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. >> >> Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. >> I added a test for printing dictionary statistics. >> >> This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. > > Coleen Phillimore 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 cht-dictionary > - Conditionalize scanning function call for safepoint. > - Use ConcurrentHashtable for Dictionary So this works because we never remove any item until we delete the entire dictionary, correct? Looks good, thanks. src/hotspot/share/utilities/globalDefinitions.hpp line 1136: > 1134: } > 1135: > 1136: // Find log2 value greater than this input This should be in utilities/powerOfTwo.hpp and then as general method. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9886 From coleenp at openjdk.org Wed Aug 24 18:10:26 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Aug 2022 18:10:26 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v5] In-Reply-To: References: Message-ID: > This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. > > Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. > I added a test for printing dictionary statistics. > > This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9886/files - new: https://git.openjdk.org/jdk/pull/9886/files/35b6f535..76451771 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9886&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9886&range=03-04 Stats: 20 lines in 4 files changed: 8 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9886.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9886/head:pull/9886 PR: https://git.openjdk.org/jdk/pull/9886 From coleenp at openjdk.org Wed Aug 24 18:10:28 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Aug 2022 18:10:28 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v4] In-Reply-To: <7XwTJ9eW-Nz1XEiQZiTS7e7RNOmKZvc9JozLI7VIlrk=.a19864dd-66a1-4515-9287-fac0d3292591@github.com> References: <7XwTJ9eW-Nz1XEiQZiTS7e7RNOmKZvc9JozLI7VIlrk=.a19864dd-66a1-4515-9287-fac0d3292591@github.com> Message-ID: On Wed, 24 Aug 2022 14:30:14 GMT, Coleen Phillimore wrote: >> This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. >> >> Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. >> I added a test for printing dictionary statistics. >> >> This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. > > Coleen Phillimore 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 cht-dictionary > - Conditionalize scanning function call for safepoint. > - Use ConcurrentHashtable for Dictionary Thank you for your comments Robbin and Johan. ------------- PR: https://git.openjdk.org/jdk/pull/9886 From coleenp at openjdk.org Wed Aug 24 18:10:32 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Aug 2022 18:10:32 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v4] In-Reply-To: References: <7XwTJ9eW-Nz1XEiQZiTS7e7RNOmKZvc9JozLI7VIlrk=.a19864dd-66a1-4515-9287-fac0d3292591@github.com> Message-ID: On Wed, 24 Aug 2022 16:03:06 GMT, Johan Sj?l?n wrote: >> Coleen Phillimore 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 cht-dictionary >> - Conditionalize scanning function call for safepoint. >> - Use ConcurrentHashtable for Dictionary > > src/hotspot/share/classfile/dictionary.cpp line 411: > >> 409: // During class loading we may have cached a protection domain that has >> 410: // since been unreferenced, so this entry should be cleared. >> 411: void Dictionary::clean_cached_protection_domains(GrowableArray* delete_list) { > > Only mention of `GrowableArray` is here and it's a pointer, so do we really need to include the `growableArray.hpp` header? A forward declaration should be sufficient. Not entirely sure, maybe the templates screw it up. We do operations on _delete_list like push below, so we need the whole header file here. > src/hotspot/share/classfile/dictionary.cpp line 412: > >> 410: // since been unreferenced, so this entry should be cleared. >> 411: void Dictionary::clean_cached_protection_domains(GrowableArray* delete_list) { >> 412: assert(JavaThread::current()->is_Java_thread(), "only called by JavaThread"); > > `JavaThread::current` already does this check, so just leave it as `Thread::current()`. > > Edit, to be clear: JavaThread::current() will fail its assertion before `->is_Java_thread()` is ever called on this line. Okay, yes, you're right, it's a bit redundant. > src/hotspot/share/classfile/dictionary.hpp line 49: > >> 47: class Config { >> 48: public: >> 49: typedef DictionaryEntry* Value; > > Nit: Is there a reason that we're mixing `using` and `typedef` (see line 55)? The Config class is defined as needing a typedef for 'Value'. I'll see if using also does the same thing. ------------- PR: https://git.openjdk.org/jdk/pull/9886 From coleenp at openjdk.org Wed Aug 24 18:10:33 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Aug 2022 18:10:33 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v4] In-Reply-To: References: <7XwTJ9eW-Nz1XEiQZiTS7e7RNOmKZvc9JozLI7VIlrk=.a19864dd-66a1-4515-9287-fac0d3292591@github.com> Message-ID: On Wed, 24 Aug 2022 17:29:50 GMT, Robbin Ehn wrote: >> Coleen Phillimore 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 cht-dictionary >> - Conditionalize scanning function call for safepoint. >> - Use ConcurrentHashtable for Dictionary > > src/hotspot/share/utilities/globalDefinitions.hpp line 1136: > >> 1134: } >> 1135: >> 1136: // Find log2 value greater than this input > > This should be in utilities/powerOfTwo.hpp and then as general method. Done. Yes that's a better place. ------------- PR: https://git.openjdk.org/jdk/pull/9886 From kvn at openjdk.org Wed Aug 24 18:31:28 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 24 Aug 2022 18:31:28 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 17:58:39 GMT, Jatin Bhateja wrote: > Hi, > > This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. > A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. > > Kindly review and share your feedback. > > Best Regards, > Jatin I got failures in my testing. I posted them in bug report. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From vlivanov at openjdk.org Wed Aug 24 19:07:48 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 24 Aug 2022 19:07:48 GMT Subject: RFR: 8292878: x86: Make scratch register usage explicit in assembler code Message-ID: Improve MacroAssembler API and make scratch register usages explicit at use sites. Different parts of JVM have different assumptions about scratch registers and implicit assumptions in MacroAssembler makes it harder to reason about the correctness of generated code. Most of scratch register usages relate to `AddressLiteral` on x86_64. In such case the argument is turned into a default one (with `noreg` as a default) and implementation asserts that scratch register should be provided when the address is not guaranteed to be always reachable. Otherwise, scratch register argument is required to be explicitly provided. The only case left (mostly) intact is `call(AddressLiteral)`, but I switched it from `rscratch` (`r10`) to `rax`. Testing: - [x] hs-tier1 - hs-tier4 (w/ -XX:+-ForceUnreachable) - [x] x86_32 build ------------- Commit messages: - x86: Make rscratch1 usages explicit Changes: https://git.openjdk.org/jdk/pull/10003/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10003&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292878 Stats: 1200 lines in 29 files changed: 224 ins; 145 del; 831 mod Patch: https://git.openjdk.org/jdk/pull/10003.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10003/head:pull/10003 PR: https://git.openjdk.org/jdk/pull/10003 From shade at openjdk.org Wed Aug 24 19:30:51 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 24 Aug 2022 19:30:51 GMT Subject: RFR: 8292867: RISC-V: Simplify weak CAS return value handling Message-ID: I see that current weak CAS implementations in `macroAssembler_riscv.cpp` return `0` on success, and then invert it in `riscv.ad` to match the Java's `boolean` result. I think we can just return the final value from `MacroAssembler`. Additional testing: - [ ] Linux RISC-V fastdebug `java/lang/invoke/VarHandles/` - [ ] Linux RISC-V fastdebug `compiler/unsafe` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/10006/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10006&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292867 Stats: 39 lines in 2 files changed: 2 ins; 13 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/10006.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10006/head:pull/10006 PR: https://git.openjdk.org/jdk/pull/10006 From mdoerr at openjdk.org Wed Aug 24 20:33:37 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 24 Aug 2022 20:33:37 GMT Subject: RFR: 8290025: Remove the Sweeper [v12] In-Reply-To: References: Message-ID: <_4qUoTaLvBdKBbMeAUW1Fjw7rtCa8fV1R8Jxl4jYM0M=.65fe0286-5e63-454b-9146-8d535afd2dd9@github.com> On Wed, 24 Aug 2022 08:53:13 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund 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 8290025_remove_sweeper > - Merge branch 'master' into 8290025_remove_sweeper > - Trigger GC from adapter blob allocations > - Zhengyu comments v1 > - Redundant variable > - Polish comment > - Merge branch 'master' into 8290025_remove_sweeper > - Removed more stale things > - Remove incorrect comment > - Feedback v2 > - ... and 2 more: https://git.openjdk.org/jdk/compare/ad2e0c4d...21d4ccb5 Thanks for the confirmation. Our CI found one issue in a test with small code cache which was already reported by Thomas above: "Thread ... died with java.lang.VirtualMachineError: Out of space in CodeCache for adapters" Do we still free up unused adapters (Method->_adapter which are classified as CodeBlobType::NonNMethod) or could this be missing, now? ------------- PR: https://git.openjdk.org/jdk/pull/9741 From svkamath at openjdk.org Wed Aug 24 21:03:53 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Wed, 24 Aug 2022 21:03:53 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v3] In-Reply-To: References: Message-ID: > 8289552: Make intrinsic conversions between bit representations of half precision values and floats Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments, updated test cases and microbenchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9781/files - new: https://git.openjdk.org/jdk/pull/9781/files/bcbc2f56..0f51243a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=01-02 Stats: 75 lines in 11 files changed: 14 ins; 28 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/9781.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781 PR: https://git.openjdk.org/jdk/pull/9781 From psandoz at openjdk.org Wed Aug 24 21:14:23 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 24 Aug 2022 21:14:23 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v3] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 21:03:53 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments, updated test cases and microbenchmark test/jdk/java/lang/Float/Binary16ConversionNaN.java line 29: > 27: * @summary Verify NaN sign and significand bits are preserved across conversions > 28: * @run main Binary16ConversionNaN > 29: * @run main/othervm/timeout=600 -XX:+UnlockDiagnosticVMOptions Do we need to specify a timeout? The tests have been running fine without intrinsics, no timeouts reports. test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 73: > 71: f16out[i] = Float.floatToFloat16(fin[i]); > 72: } > 73: bh.consume(f16out); You can simplify to this: Suggestion: public float floatToFloat16() { for (int i = 0; i < fin.length; i++) { f16out[i] = Float.floatToFloat16(fin[i]); } return f16out; ------------- PR: https://git.openjdk.org/jdk/pull/9781 From kvn at openjdk.org Wed Aug 24 21:20:24 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 24 Aug 2022 21:20:24 GMT Subject: RFR: 8292878: x86: Make scratch register usage explicit in assembler code In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 18:42:28 GMT, Vladimir Ivanov wrote: > Improve MacroAssembler API and make scratch register usages explicit at use sites. > > Different parts of JVM have different assumptions about scratch registers and > implicit assumptions in MacroAssembler makes it harder to reason about the > correctness of generated code. > > Most of scratch register usages relate to `AddressLiteral` on x86_64. In such case the argument is turned into a default one (with `noreg` as a default) and implementation asserts that scratch register should be provided when the address is not guaranteed to be always reachable. > > Otherwise, scratch register argument is required to be explicitly provided. > > The only case left (mostly) intact is `call(AddressLiteral)`, but I switched it from `rscratch` (`r10`) to `rax`. > > Testing: > - [x] hs-tier1 - hs-tier4 (w/ -XX:+-ForceUnreachable) > - [x] x86_32 build I hope you did not do this all by hand ;) Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10003 From coleenp at openjdk.org Wed Aug 24 22:35:50 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Aug 2022 22:35:50 GMT Subject: RFR: 8292890: Remove PrintTouchedMethodsAtExit and LogTouchedMethods Message-ID: These options were implemented for a CDS feature to move methods in the shared region, but was never used. I noticed them in converting rogue ad-hoc hashtables to ResourceHashtable. The Hashtable for touched methods keeps all methods referred to in a giant hashtable, and keeps the Symbols for the name, class and signature from being deleted by incrementing the refcounts. This should just be removed since it's not used, and in the future if we needed this, we would implement it differently. Testing with tier1 on Oracle platforms, tier1-3 on linux-x64-debug, linux-x64, windows-x64-debug, and other platforms builds-only. In progress. ------------- Commit messages: - 8292890: Remove PrintTouchedMethodsAtExit and LogTouchedMethods - Use ResourceHashtable for TouchedMethodTable Changes: https://git.openjdk.org/jdk/pull/10009/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10009&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292890 Stats: 364 lines in 19 files changed: 0 ins; 350 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/10009.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10009/head:pull/10009 PR: https://git.openjdk.org/jdk/pull/10009 From iklam at openjdk.org Wed Aug 24 22:38:16 2022 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 24 Aug 2022 22:38:16 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions Message-ID: Some CDS functions are always compiled, even when CDS is not enabled (e.g., for the minimal VM). This RFE puts some of the obvious ones inside `#if INCLUDE_CDS` blocks. Note: my goal is not to make the minimal VM as small as possible. But rather, I don't want to put `#if INCLUDE_CDS` inside each of those functions that access a CDS-only feature. (E.g., `ConstantPoolCache::save_for_archive`, which accesses `_initial_entries`, which is declared only when CDS is enabled). ------------- Commit messages: - 8292891: ifdef-out some CDS-only functions Changes: https://git.openjdk.org/jdk/pull/10010/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10010&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292891 Stats: 49 lines in 15 files changed: 34 ins; 11 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10010.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10010/head:pull/10010 PR: https://git.openjdk.org/jdk/pull/10010 From coleenp at openjdk.org Wed Aug 24 22:38:17 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Aug 2022 22:38:17 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 22:27:48 GMT, Ioi Lam wrote: > Some CDS functions are always compiled, even when CDS is not enabled (e.g., for the minimal VM). > > This RFE puts some of the obvious ones inside `#if INCLUDE_CDS` blocks. > > Note: my goal is not to make the minimal VM as small as possible. But rather, I don't want to put `#if INCLUDE_CDS` inside each of those functions that access a CDS-only feature. (E.g., `ConstantPoolCache::save_for_archive`, which accesses `_initial_entries`, which is declared only when CDS is enabled). Looks good to have the largest if blocks possible. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/10010 From svkamath at openjdk.org Wed Aug 24 23:05:34 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Wed, 24 Aug 2022 23:05:34 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v4] In-Reply-To: References: Message-ID: <8AdMeA4Li_c8bN5BJWwGHDPYVb9sBFz_m40iv9Sc27c=.d3c527da-dce5-4425-b979-5473dcb3640b@github.com> > 8289552: Make intrinsic conversions between bit representations of half precision values and floats Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Updated test cases as per review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9781/files - new: https://git.openjdk.org/jdk/pull/9781/files/0f51243a..7cfed790 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=02-03 Stats: 7 lines in 3 files changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9781.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781 PR: https://git.openjdk.org/jdk/pull/9781 From psandoz at openjdk.org Wed Aug 24 23:10:33 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 24 Aug 2022 23:10:33 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v4] In-Reply-To: <8AdMeA4Li_c8bN5BJWwGHDPYVb9sBFz_m40iv9Sc27c=.d3c527da-dce5-4425-b979-5473dcb3640b@github.com> References: <8AdMeA4Li_c8bN5BJWwGHDPYVb9sBFz_m40iv9Sc27c=.d3c527da-dce5-4425-b979-5473dcb3640b@github.com> Message-ID: <70BYvagN3fE5tGE5vsD-pgXrLcH5qHRN0E106OloeCg=.55dc91a3-c88e-404d-b720-f34090a493f3@github.com> On Wed, 24 Aug 2022 23:05:34 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated test cases as per review comments test/micro/org/openjdk/bench/java/math/Fp16ConversionBenchmark.java line 1: > 1: // Can you update the copyright comment to be consistent with other source, and also correct the year to be only 2022? e.g. copy that from `Binary16Conversion.java`. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From vlivanov at openjdk.org Wed Aug 24 23:33:32 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 24 Aug 2022 23:33:32 GMT Subject: RFR: 8292203: AArch64: Represent Registers as values [v5] In-Reply-To: References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> Message-ID: On Wed, 24 Aug 2022 03:48:17 GMT, Vladimir Ivanov wrote: >> (It's a PR dependent on #9815.) >> >> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation. >> >> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types. >> >> Proposed change hides pointer representation behind value class. >> >> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). >> >> Code quality improves: >> GCC: https://godbolt.org/z/r6G36facj >> Clang: https://godbolt.org/z/x5oPdYEPM >> >> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) >> >> Testing: hs-tier1 - hs-tier5 >> >> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into rwrapper.aarch64 > - Merge branch 'master' into rwrapper.aarch64 > - explicit constructors > - Merge branch 'master' into rwrapper.aarch64 > - 8292203: AArch64: Represent Registers as values > - cleanups > - x86: Register class wrappers Thanks for the review, Vladimir. Anybody else planning to review? Otherwise, I'll push it tomorrow. ------------- PR: https://git.openjdk.org/jdk/pull/9826 From svkamath at openjdk.org Wed Aug 24 23:48:36 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Wed, 24 Aug 2022 23:48:36 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v5] In-Reply-To: References: Message-ID: > 8289552: Make intrinsic conversions between bit representations of half precision values and floats Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Updated copyright comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9781/files - new: https://git.openjdk.org/jdk/pull/9781/files/7cfed790..1570e244 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=03-04 Stats: 23 lines in 1 file changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/9781.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781 PR: https://git.openjdk.org/jdk/pull/9781 From dholmes at openjdk.org Wed Aug 24 23:57:31 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 24 Aug 2022 23:57:31 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v3] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 14:23:49 GMT, Johan Sj?l?n wrote: >> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? >> >> This PR does 3 things: >> >> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot >> * Adds some new utilities for writing multi-threaded tests. >> * Adds some tests for MRSW Mutex using these new utilities >> >> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 >> >> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > > Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: > > - Update documentation > - Fix outdated headers and remove dead code As a stand-alone RWL implementation with the described properties and limitations this seems okay to me. Whether this RWL implementation will turn out to be useful for any existing subsystems without exhibiting performance pathologies or bad interactions with existing synchronization code is just something we will have to see. However, as we tend not to encourage unused code it would perhaps be better to delay integration of this until there is an actual usecase ready for it. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From ccheung at openjdk.org Thu Aug 25 00:04:20 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 25 Aug 2022 00:04:20 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 22:27:48 GMT, Ioi Lam wrote: > Some CDS functions are always compiled, even when CDS is not enabled (e.g., for the minimal VM). > > This RFE puts some of the obvious ones inside `#if INCLUDE_CDS` blocks. > > Note: my goal is not to make the minimal VM as small as possible. But rather, I don't want to put `#if INCLUDE_CDS` inside each of those functions that access a CDS-only feature. (E.g., `ConstantPoolCache::save_for_archive`, which accesses `_initial_entries`, which is declared only when CDS is enabled). Thanks for the cleanup. One comment below. src/hotspot/share/oops/method.cpp line 404: > 402: } > 403: > 404: #if INCLUDE_CDS Do you need to ifdef out the declaration in method.hpp? ------------- PR: https://git.openjdk.org/jdk/pull/10010 From pli at openjdk.org Thu Aug 25 00:50:13 2022 From: pli at openjdk.org (Pengfei Li) Date: Thu, 25 Aug 2022 00:50:13 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 13:06:41 GMT, Roland Westrelin wrote: >> Recently, an igvn infinite loop issue was reported. Git bisection shows >> it appears after our JDK-8289996 patch. But after that patch is backed >> out, we find similar test still fails. We have attached a jtreg case to >> reproduce this issue. >> >> The ideal graph of the problematic method has a `MulINode` multiplying a >> `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` >> moves the constant input to the right hand side. And `Ideal()` function >> in its parent class `MulNode` has the similar logic. In some code paths, >> `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, >> `MulINode` and `MulNode` use different ways to check constant. One calls >> `type->singleton()` and the other calls `node->find_int_con(val)` which >> accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` >> can be evaluated to a constant, the two inputs of the `MulNode` will be >> swapped back and forth in `Ideal()` calls. It eventually causes the igvn >> infinite loop issue. >> >> This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` >> because it's enough to do this by calling `MulNode::Ideal()`. We also do >> some code cleanup in this patch as we have done in JDK-8289996. >> >> Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. > > src/hotspot/share/opto/mulnode.cpp line 252: > >> 250: >> 251: // Now we have a constant Node on the right and the constant in con >> 252: if (con == 0) return NULL; // By zero is handled by Value call > > Value() runs after Ideal so why wouldn't we have con == 0 here? This Ideal function is returned in `if ((con = in(2)->find_int_con(0)) == 0)` block above if we have `con == 0`. So this line is actually unreachable. ------------- PR: https://git.openjdk.org/jdk/pull/9820 From kbarrett at openjdk.org Thu Aug 25 00:56:32 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 25 Aug 2022 00:56:32 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 05:56:52 GMT, Kim Barrett wrote: > It's probably worth having comments referring to the corresponding Hacker's Delight sections for both of these functions. Hm, except this *isn't* the Hacker's Delight algorithm (which is the same as the seander bithacks algorithm). Is there a reference for this algorithm? I'd prefer something "well known" to something whose correctness I need to think hard about. I'm not spotting anything wrong here (though I think there should be more parenthesis so I don't need to think about the precedence between shift operators and bitwise-or), but @vnkozlov is reporting failures with these changes. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From psandoz at openjdk.org Thu Aug 25 01:05:35 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 25 Aug 2022 01:05:35 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v5] In-Reply-To: References: Message-ID: <_froabAuebhqaoCfObNUz1_bFdIzJ9KgOrxWuHlHbUI=.f309fd00-a4c0-4bb1-9dd5-bac5cfb9514b@github.com> On Wed, 24 Aug 2022 23:48:36 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright comment Java code looks good (HotSpot reviewers also need to approve). ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.org/jdk/pull/9781 From kbarrett at openjdk.org Thu Aug 25 01:09:32 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 25 Aug 2022 01:09:32 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 17:58:39 GMT, Jatin Bhateja wrote: > Hi, > > This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. > A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. > > Kindly review and share your feedback. > > Best Regards, > Jatin Changes requested by kbarrett (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9987 From kbarrett at openjdk.org Thu Aug 25 01:09:34 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 25 Aug 2022 01:09:34 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 In-Reply-To: References: Message-ID: <370LtCIDfWIj7vKs7TB_HVBC6uI6vx_AcmbopRbxM6s=.8fd6f803-34f1-4147-863e-c533237376ac@github.com> On Thu, 25 Aug 2022 00:54:29 GMT, Kim Barrett wrote: >> src/hotspot/share/utilities/moveBits.hpp line 31: >> >>> 29: #include "utilities/globalDefinitions.hpp" >>> 30: >>> 31: inline uint64_t bit_reverse(uint64_t x) { >> >> It's probably worth having comments referring to the corresponding Hacker's Delight sections for both of these functions. > >> It's probably worth having comments referring to the corresponding Hacker's Delight sections for both of these functions. > > Hm, except this *isn't* the Hacker's Delight algorithm (which is the same as the seander bithacks algorithm). Is there a reference for this algorithm? I'd prefer something "well known" to something whose correctness I need to think hard about. I'm not spotting anything wrong here (though I think there should be more parenthesis so I don't need to think about the precedence between shift operators and bitwise-or), but @vnkozlov is reporting failures with these changes. On further consideration, I don't care whether this code is correct. It should be replaced with the Hacker's Delight algorithm, which is simply better because it uses half as many large constants (which can be expensive to form on some platforms). ------------- PR: https://git.openjdk.org/jdk/pull/9987 From psandoz at openjdk.org Thu Aug 25 01:10:21 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 25 Aug 2022 01:10:21 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v5] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 23:48:36 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright comment A general comment: since there is native runtime code to perform conversions for constants (IIRC) I think we need to some special tests to verify that works correctly (shame there is no way to leverage the Java code in such cases). It might require some advice from other HotSpot engineers, but i think we do need to follow up with another PR on that aspect. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From rsunderbabu at openjdk.org Thu Aug 25 01:40:54 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Thu, 25 Aug 2022 01:40:54 GMT Subject: Integrated: 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 14:03:34 GMT, Ramkumar Sunderbabu wrote: > Tested with all GC options This pull request has now been integrated. Changeset: 7b81a9c7 Author: Ramkumar Sunderbabu Committer: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/7b81a9c75d60f6eb2727515bacfffcf7cf15e128 Stats: 1349 lines in 50 files changed: 29 ins; 1280 del; 40 mod 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" Reviewed-by: lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/9658 From yadongwang at openjdk.org Thu Aug 25 02:06:27 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Thu, 25 Aug 2022 02:06:27 GMT Subject: RFR: 8292867: RISC-V: Simplify weak CAS return value handling In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 19:23:29 GMT, Aleksey Shipilev wrote: > I see that current weak CAS implementations in `macroAssembler_riscv.cpp` return `0` on success, and then invert it in `riscv.ad` to match the Java's `boolean` result. I think we can just return the final value from `MacroAssembler`. > > Additional testing: > - [ ] Linux RISC-V fastdebug `java/lang/invoke/VarHandles/` > - [ ] Linux RISC-V fastdebug `compiler/unsafe` lgtm ------------- Marked as reviewed by yadongwang (Author). PR: https://git.openjdk.org/jdk/pull/10006 From fyang at openjdk.org Thu Aug 25 02:55:19 2022 From: fyang at openjdk.org (Fei Yang) Date: Thu, 25 Aug 2022 02:55:19 GMT Subject: RFR: 8292867: RISC-V: Simplify weak CAS return value handling In-Reply-To: References: Message-ID: <_UoFxZZ5nOi2AMrxg3zU0H4M44dti9EUdlF-DFKU0pw=.4312cd6b-423d-4492-b9b0-fae0eacbd57b@github.com> On Wed, 24 Aug 2022 19:23:29 GMT, Aleksey Shipilev wrote: > I see that current weak CAS implementations in `macroAssembler_riscv.cpp` return `0` on success, and then invert it in `riscv.ad` to match the Java's `boolean` result. I think we can just return the final value from `MacroAssembler`. > > Additional testing: > - [ ] Linux RISC-V fastdebug `java/lang/invoke/VarHandles/` > - [ ] Linux RISC-V fastdebug `compiler/unsafe` Looks fine. I checked that we covered all the callsites of the macro assembler function. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10006 From sviswanathan at openjdk.org Thu Aug 25 03:18:42 2022 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 25 Aug 2022 03:18:42 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v5] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 23:48:36 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright comment src/hotspot/cpu/x86/x86.ad line 1686: > 1684: case Op_ConvHF2F: > 1685: if (!VM_Version::supports_f16c() && !VM_Version::supports_evex() && > 1686: !VM_Version::supports_avx512vl()) { The condition should be: if (!VM_Version::supports_f16c() && !(VM_Version::supports_evex() && VM_Version::supports_avx512vl())) { return false; } For AVX-512 both evex and avx512vl are needed. src/hotspot/cpu/x86/x86_64.ad line 11320: > 11318: ins_pipe( pipe_slow ); > 11319: %} > 11320: For F2HF, good to also add optimized rule with StoreC to benefit from vcvtps2ph memory destination form of instruction. match(Set mem (StoreC mem (ConvF2HF src))); src/hotspot/cpu/x86/x86_64.ad line 11330: > 11328: ins_pipe( pipe_slow ); > 11329: %} > 11330: For HF2F, good to also add optimized rule with LoadS to benefit from vcvtph2ps memory src form of instruction. match(Set dst (ConvHF2F ( LoadS mem))); ------------- PR: https://git.openjdk.org/jdk/pull/9781 From dholmes at openjdk.org Thu Aug 25 04:55:27 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 Aug 2022 04:55:27 GMT Subject: RFR: 8292671: Hotspot Style Guide should allow covariant returns In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 14:12:05 GMT, Roland Westrelin wrote: > The style guide explicitly lists covariant returns as a disallowed > feature of c++. I propose we allow that feature. > > This came up on the c2 side where, with JDK-8275201, I introduced some > uses of covariant returns at a number of locations in the c2 code > because I felt the code was cleaner that way. I wasn't aware it was > mentioned on the style guide. This was noticed by another openjdk > contributor and I prepared a change to revert the use of covariant > returns I had introduced: > > https://github.com/openjdk/jdk/pull/9237 > > But it feels that change actually makes the code less clear and > comments on the PR indicates some other contributors feel the same > way. > > It's unclear to me why covariant returns are disallowed in the first > place and the (few) contributors I asked don't seem to know either. So > I propose simply allowing covariant returns. I have no concerns with this. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9941 From stefank at openjdk.org Thu Aug 25 06:09:30 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 25 Aug 2022 06:09:30 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory [v2] In-Reply-To: References: Message-ID: <54k4QZxdzCTj29jsLcnWtlZ5HtXxN4Zl7X4aqUmgObQ=.1ddad8cd-3ead-4356-8346-821fa0ca7aa1@github.com> > HotSpot performs "critical metaspace allocations" when it's running out of metaspace. The failed allocations are registered in a queue, which the GC prioritizes when cleaning up the metaspace. There's a race in the code that handles these requests. > > These requests are added to the queue, and the GC will "process" each request in turn when it runs the metaspace purge phase. The queue handling has an optimization that says that only the first request in the queue needs to trigger the GC, all subsequent requests in the queue will wait for that GC. When the GC gets to the purge phase it will mark in all requests that they have been processed. Note: that this doesn't mean that the request was satisfied, it could be that the result was NULL (and the thread will trigger a last-effort GC before it throws an OOME). > > The bug is in the code that determines if a request is responsible for triggering a new GC. The current code just checks if the current request is first in the queue. This doesn't work if the code is called just after the GC has run purge, but before the old requests have been removed. The new request sees that there are already elements in the queue, so it doesn't trigger the GC. And at the same time, the old requests have been processed and they won't trigger the GC either. So, now the new request is waiting for a GC that will not be triggered by anyone. > > Note: The reason why there's a delay between the GC processing a request, and the removal from the queue, is that the Java thread that added the request is also responsible for removing the request form the queue. The reason for this is that the mentioned last-effort GC, needs to be able to process the request a second time. > > The fix-proposal is to let threads adding new requests check if the added request is the first *non-processed* request in the queue. If it is, that request/thread is responsible for triggering the GC for itself, and any subsequently added requests (until the GC runs the next round of request processing). > > However, there's a snatch to this proposal. The request processing is done inside `Metaspace::purge()`, and that function is skipped if the GC didn't unload any classes. The proposed logic relies on that function to always be run when a GC is running. So, I've also changed so that the GC unconditionally calls the request processing. An alternative would be to always run the Metaspace::purge() code. That might even help return memory from temporarily allocated metaspace memory earlier, but I've left that exercise for a potential future improvement. > > I've also tweaked the test so that we get a bit more info if this test fails again. > > Testing: I could reliably reproduce the original hang on my macbook laptop, within a few minutes. With this fix I can run the test in a loop for hours without reproducing the hang. I've tested this together with Generational ZGC code, running tier1-tier7 on Linux x64. I've started more extensive testing on openjdk/jdk. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Update test text ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9985/files - new: https://git.openjdk.org/jdk/pull/9985/files/aa89d763..0186424d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9985&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9985&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9985.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9985/head:pull/9985 PR: https://git.openjdk.org/jdk/pull/9985 From iklam at openjdk.org Thu Aug 25 06:18:36 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 25 Aug 2022 06:18:36 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v2] In-Reply-To: References: Message-ID: > Some CDS functions are always compiled, even when CDS is not enabled (e.g., for the minimal VM). > > This RFE puts some of the obvious ones inside `#if INCLUDE_CDS` blocks. > > Note: my goal is not to make the minimal VM as small as possible. But rather, I don't want to put `#if INCLUDE_CDS` inside each of those functions that access a CDS-only feature. (E.g., `ConstantPoolCache::save_for_archive`, which accesses `_initial_entries`, which is declared only when CDS is enabled). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @calvinccheung comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10010/files - new: https://git.openjdk.org/jdk/pull/10010/files/1a42c1db..9941eb7e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10010&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10010&range=00-01 Stats: 14 lines in 2 files changed: 5 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10010.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10010/head:pull/10010 PR: https://git.openjdk.org/jdk/pull/10010 From iklam at openjdk.org Thu Aug 25 06:18:37 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 25 Aug 2022 06:18:37 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v2] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 00:00:18 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @calvinccheung comments > > src/hotspot/share/oops/method.cpp line 404: > >> 402: } >> 403: >> 404: #if INCLUDE_CDS > > Do you need to ifdef out the declaration in method.hpp? Fixed. I also found out that `Method::restore_unshareable_info` also needed to be ifdef'ed out. ------------- PR: https://git.openjdk.org/jdk/pull/10010 From mbaesken at openjdk.org Thu Aug 25 08:28:37 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 25 Aug 2022 08:28:37 GMT Subject: RFR: JDK-8292903: enhance round_up_power_of_2 assertion output Message-ID: There is an assertion in round_up_power_of_2 for value <= max_power_of_2 of the type; would be nice to show the value of the problematic argument in case of failures. ------------- Commit messages: - JDK-8292903 Changes: https://git.openjdk.org/jdk/pull/10016/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10016&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292903 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10016.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10016/head:pull/10016 PR: https://git.openjdk.org/jdk/pull/10016 From roland at openjdk.org Thu Aug 25 08:45:29 2022 From: roland at openjdk.org (Roland Westrelin) Date: Thu, 25 Aug 2022 08:45:29 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN In-Reply-To: References: Message-ID: <1NFoDPRrsPLi3hsc8l0kl1HTIfebbfAjezP0-ASDtis=.cc2874b4-ffd4-4310-b61c-aec1233f45ae@github.com> On Thu, 25 Aug 2022 00:47:06 GMT, Pengfei Li wrote: >> src/hotspot/share/opto/mulnode.cpp line 252: >> >>> 250: >>> 251: // Now we have a constant Node on the right and the constant in con >>> 252: if (con == 0) return NULL; // By zero is handled by Value call >> >> Value() runs after Ideal so why wouldn't we have con == 0 here? > > This Ideal function is returned in `if ((con = in(2)->find_int_con(0)) == 0)` block above if we have `con == 0`. So this line is actually unreachable. Ok. Can you reword the comment to state that explicitly? ------------- PR: https://git.openjdk.org/jdk/pull/9820 From tschatzl at openjdk.org Thu Aug 25 08:51:39 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 25 Aug 2022 08:51:39 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation Message-ID: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Hi all, can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is ------------- Commit messages: - disable G1EvacuationFailureALot by default again - Remove unneeded clear metadata phase - Remove debug code - More refactoring - Initial cleanup - some refactoring, fix clearing of opt index in cset - fix test - some cleanup - Cleanup, phase names, fixes - fixes for single bitmap - ... and 1 more: https://git.openjdk.org/jdk/compare/f2f0cd86...6fc07344 Changes: https://git.openjdk.org/jdk/pull/9980/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9980&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8256265 Stats: 498 lines in 22 files changed: 271 ins; 97 del; 130 mod Patch: https://git.openjdk.org/jdk/pull/9980.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9980/head:pull/9980 PR: https://git.openjdk.org/jdk/pull/9980 From eosterlund at openjdk.org Thu Aug 25 09:10:20 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 25 Aug 2022 09:10:20 GMT Subject: RFR: 8290025: Remove the Sweeper [v13] In-Reply-To: References: Message-ID: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Missing PPC code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9741/files - new: https://git.openjdk.org/jdk/pull/9741/files/21d4ccb5..93f29a69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9741&range=11-12 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9741/head:pull/9741 PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 25 09:10:23 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 25 Aug 2022 09:10:23 GMT Subject: RFR: 8290025: Remove the Sweeper [v12] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 08:53:13 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund 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 8290025_remove_sweeper > - Merge branch 'master' into 8290025_remove_sweeper > - Trigger GC from adapter blob allocations > - Zhengyu comments v1 > - Redundant variable > - Polish comment > - Merge branch 'master' into 8290025_remove_sweeper > - Removed more stale things > - Remove incorrect comment > - Feedback v2 > - ... and 2 more: https://git.openjdk.org/jdk/compare/ad2e0c4d...21d4ccb5 > ```diff > + if (!supports_entry_barrier(nm)) { > + return; > + } > + > + NativeNMethodBarrier* barrier = get_nmethod_barrier(nm); > + barrier->release_set_guard_value(arm_value); > ``` I added the missing PPC code, thank you. As far as adapters go, I don't believe we have ever removed any. We have relied on caching/sharing of adapters of the same signature to keep the footprint down. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From aph at openjdk.org Thu Aug 25 09:14:46 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 25 Aug 2022 09:14:46 GMT Subject: RFR: 8292203: AArch64: Represent Registers as values [v5] In-Reply-To: References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> Message-ID: On Wed, 24 Aug 2022 03:48:17 GMT, Vladimir Ivanov wrote: >> (It's a PR dependent on #9815.) >> >> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation. >> >> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types. >> >> Proposed change hides pointer representation behind value class. >> >> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). >> >> Code quality improves: >> GCC: https://godbolt.org/z/r6G36facj >> Clang: https://godbolt.org/z/x5oPdYEPM >> >> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) >> >> Testing: hs-tier1 - hs-tier5 >> >> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into rwrapper.aarch64 > - Merge branch 'master' into rwrapper.aarch64 > - explicit constructors > - Merge branch 'master' into rwrapper.aarch64 > - 8292203: AArch64: Represent Registers as values > - cleanups > - x86: Register class wrappers Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9826 From stefank at openjdk.org Thu Aug 25 09:14:46 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 25 Aug 2022 09:14:46 GMT Subject: RFR: JDK-8292903: enhance round_up_power_of_2 assertion output In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 08:20:49 GMT, Matthias Baesken wrote: > There is an assertion in round_up_power_of_2 for value <= max_power_of_2 of the type; would be nice to show the value of the problematic argument in case of failures. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10016 From mdoerr at openjdk.org Thu Aug 25 09:36:14 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 25 Aug 2022 09:36:14 GMT Subject: RFR: 8290025: Remove the Sweeper [v13] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 09:10:20 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Missing PPC code Thanks for adding it! Looks good from our side. Our CI didn't find any other problems and we can still look into handling of adapters after this change. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From pli at openjdk.org Thu Aug 25 09:44:47 2022 From: pli at openjdk.org (Pengfei Li) Date: Thu, 25 Aug 2022 09:44:47 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN [v2] In-Reply-To: References: Message-ID: <4-3rk63k1x5ElcfNiAN0iEWHFerxELQa1Gn3fDfzrTQ=.e3db4433-2c10-4803-a84b-5fcafc14f81e@github.com> > Recently, an igvn infinite loop issue was reported. Git bisection shows > it appears after our JDK-8289996 patch. But after that patch is backed > out, we find similar test still fails. We have attached a jtreg case to > reproduce this issue. > > The ideal graph of the problematic method has a `MulINode` multiplying a > `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` > moves the constant input to the right hand side. And `Ideal()` function > in its parent class `MulNode` has the similar logic. In some code paths, > `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, > `MulINode` and `MulNode` use different ways to check constant. One calls > `type->singleton()` and the other calls `node->find_int_con(val)` which > accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` > can be evaluated to a constant, the two inputs of the `MulNode` will be > swapped back and forth in `Ideal()` calls. It eventually causes the igvn > infinite loop issue. > > This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` > because it's enough to do this by calling `MulNode::Ideal()`. We also do > some code cleanup in this patch as we have done in JDK-8289996. > > Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. Pengfei Li has updated the pull request incrementally with one additional commit since the last revision: Reword some comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9820/files - new: https://git.openjdk.org/jdk/pull/9820/files/8ca74190..7272ce10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9820&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9820&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9820.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9820/head:pull/9820 PR: https://git.openjdk.org/jdk/pull/9820 From pli at openjdk.org Thu Aug 25 09:44:49 2022 From: pli at openjdk.org (Pengfei Li) Date: Thu, 25 Aug 2022 09:44:49 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN [v2] In-Reply-To: <1NFoDPRrsPLi3hsc8l0kl1HTIfebbfAjezP0-ASDtis=.cc2874b4-ffd4-4310-b61c-aec1233f45ae@github.com> References: <1NFoDPRrsPLi3hsc8l0kl1HTIfebbfAjezP0-ASDtis=.cc2874b4-ffd4-4310-b61c-aec1233f45ae@github.com> Message-ID: On Thu, 25 Aug 2022 08:42:10 GMT, Roland Westrelin wrote: >> This Ideal function is returned in `if ((con = in(2)->find_int_con(0)) == 0)` block above if we have `con == 0`. So this line is actually unreachable. > > Ok. Can you reword the comment to state that explicitly? Done in latest commit ------------- PR: https://git.openjdk.org/jdk/pull/9820 From eosterlund at openjdk.org Thu Aug 25 09:50:28 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 25 Aug 2022 09:50:28 GMT Subject: RFR: 8290025: Remove the Sweeper [v13] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 09:33:05 GMT, Martin Doerr wrote: > Thanks for adding it! Looks good from our side. Our CI didn't find any other problems and we can still look into handling of adapters after this change. Thank you Martin! ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Thu Aug 25 09:51:59 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 25 Aug 2022 09:51:59 GMT Subject: Integrated: 8290025: Remove the Sweeper In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 09:02:02 GMT, Erik ?sterlund wrote: > When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. > > The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. > > With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. > > The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. > > I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: > 1. Unlink > 2. Global sync > 3. Throw away > 4. Profit! > This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. > > In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. > > I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. > > I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. This pull request has now been integrated. Changeset: 054c23f4 Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/054c23f484522881a0879176383d970a8de41201 Stats: 4124 lines in 189 files changed: 565 ins; 2991 del; 568 mod 8290025: Remove the Sweeper Reviewed-by: stefank, kvn, iveresov, coleenp, vlivanov, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/9741 From stuefe at openjdk.org Thu Aug 25 10:10:34 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 25 Aug 2022 10:10:34 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v3] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 14:23:49 GMT, Johan Sj?l?n wrote: >> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? >> >> This PR does 3 things: >> >> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot >> * Adds some new utilities for writing multi-threaded tests. >> * Adds some tests for MRSW Mutex using these new utilities >> >> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 >> >> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > > Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: > > - Update documentation > - Fix outdated headers and remove dead code I don't have time to review, just chiming in that I look forward to use RWL in NMT, to simplify the lockless MST. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From aboldtch at openjdk.org Thu Aug 25 10:21:05 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 25 Aug 2022 10:21:05 GMT Subject: RFR: 8292868: Explicitly pass a third temp register to MacroAssembler::store_heap_oop for aarch64 Message-ID: Currently G1 (and Shenandoah) implicitly uses r3 on aarch64 in store_at. This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). This would be fixed in the same way on aarch64 by passing the temporary register explicitly so it is part of the GC api Testing: Oracle aarch64 platforms tier 1-3 ------------- Commit messages: - Remove implicit tmp register aarch64 store_at Changes: https://git.openjdk.org/jdk/pull/10019/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10019&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292868 Stats: 68 lines in 16 files changed: 2 ins; 0 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/10019.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10019/head:pull/10019 PR: https://git.openjdk.org/jdk/pull/10019 From stuefe at openjdk.org Thu Aug 25 11:00:14 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 25 Aug 2022 11:00:14 GMT Subject: RFR: JDK-8292903: enhance round_up_power_of_2 assertion output In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 08:20:49 GMT, Matthias Baesken wrote: > There is an assertion in round_up_power_of_2 for value <= max_power_of_2 of the type; would be nice to show the value of the problematic argument in case of failures. +1 ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/10016 From shade at openjdk.org Thu Aug 25 11:27:26 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 25 Aug 2022 11:27:26 GMT Subject: RFR: 8292868: Explicitly pass a third temp register to MacroAssembler::store_heap_oop for aarch64 In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 10:11:30 GMT, Axel Boldt-Christmas wrote: > Currently G1 (and Shenandoah) implicitly uses r3 on aarch64 in store_at. > > This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). This would be fixed in the same way on aarch64 by passing the temporary register explicitly so it is part of the GC api > > Testing: Oracle aarch64 platforms tier 1-3 Looks fine. I tested cross-builds on many platforms. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10019 From duke at openjdk.org Thu Aug 25 11:37:21 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Thu, 25 Aug 2022 11:37:21 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v5] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 18:10:26 GMT, Coleen Phillimore wrote: >> This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. >> >> Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. >> I added a test for printing dictionary statistics. >> >> This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Review comments. LGTM, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9886 From mbaesken at openjdk.org Thu Aug 25 11:46:30 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 25 Aug 2022 11:46:30 GMT Subject: RFR: JDK-8292903: enhance round_up_power_of_2 assertion output In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 08:20:49 GMT, Matthias Baesken wrote: > There is an assertion in round_up_power_of_2 for value <= max_power_of_2 of the type; would be nice to show the value of the problematic argument in case of failures. Hi Stefan and Thomas, thanks for the reviews. ------------- PR: https://git.openjdk.org/jdk/pull/10016 From coleenp at openjdk.org Thu Aug 25 11:47:28 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 25 Aug 2022 11:47:28 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v2] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 06:18:36 GMT, Ioi Lam wrote: >> Some CDS functions are always compiled, even when CDS is not enabled (e.g., for the minimal VM). >> >> This RFE puts some of the obvious ones inside `#if INCLUDE_CDS` blocks. >> >> Note: my goal is not to make the minimal VM as small as possible. But rather, I don't want to put `#if INCLUDE_CDS` inside each of those functions that access a CDS-only feature. (E.g., `ConstantPoolCache::save_for_archive`, which accesses `_initial_entries`, which is declared only when CDS is enabled). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @calvinccheung comments src/hotspot/share/oops/klass.hpp line 575: > 573: } > 574: } > 575: #endif Can you add an // INCLUDE_CDS here? If they're more than 10 lines apart, uncommented endifs can be really confusing. This one is sort of borderline far away. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10010 From coleenp at openjdk.org Thu Aug 25 12:29:17 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 25 Aug 2022 12:29:17 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v3] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 10:07:05 GMT, Thomas Stuefe wrote: >> Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update documentation >> - Fix outdated headers and remove dead code > > I don't have time to review, just chiming in that I look forward to use RWL in NMT, to simplify the lockless MST. @tstuefe I have a memory of there being a lock like this in NMT, but it must have been removed. If there's an upcoming use of this RWL lock, then we should integrate it first and not bundle it with the client code. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From roland at openjdk.org Thu Aug 25 12:37:30 2022 From: roland at openjdk.org (Roland Westrelin) Date: Thu, 25 Aug 2022 12:37:30 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN [v2] In-Reply-To: <4-3rk63k1x5ElcfNiAN0iEWHFerxELQa1Gn3fDfzrTQ=.e3db4433-2c10-4803-a84b-5fcafc14f81e@github.com> References: <4-3rk63k1x5ElcfNiAN0iEWHFerxELQa1Gn3fDfzrTQ=.e3db4433-2c10-4803-a84b-5fcafc14f81e@github.com> Message-ID: On Thu, 25 Aug 2022 09:44:47 GMT, Pengfei Li wrote: >> Recently, an igvn infinite loop issue was reported. Git bisection shows >> it appears after our JDK-8289996 patch. But after that patch is backed >> out, we find similar test still fails. We have attached a jtreg case to >> reproduce this issue. >> >> The ideal graph of the problematic method has a `MulINode` multiplying a >> `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` >> moves the constant input to the right hand side. And `Ideal()` function >> in its parent class `MulNode` has the similar logic. In some code paths, >> `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, >> `MulINode` and `MulNode` use different ways to check constant. One calls >> `type->singleton()` and the other calls `node->find_int_con(val)` which >> accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` >> can be evaluated to a constant, the two inputs of the `MulNode` will be >> swapped back and forth in `Ideal()` calls. It eventually causes the igvn >> infinite loop issue. >> >> This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` >> because it's enough to do this by calling `MulNode::Ideal()`. We also do >> some code cleanup in this patch as we have done in JDK-8289996. >> >> Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. > > Pengfei Li has updated the pull request incrementally with one additional commit since the last revision: > > Reword some comments Looks good to me. ------------- Marked as reviewed by roland (Reviewer). PR: https://git.openjdk.org/jdk/pull/9820 From stuefe at openjdk.org Thu Aug 25 12:44:31 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 25 Aug 2022 12:44:31 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v3] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 10:07:05 GMT, Thomas Stuefe wrote: >> Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update documentation >> - Fix outdated headers and remove dead code > > I don't have time to review, just chiming in that I look forward to use RWL in NMT, to simplify the lockless MST. > @tstuefe I have a memory of there being a lock like this in NMT, but it must have been removed. > There is a lock for queries. MST is lockless for normal operations, which makes the table a bit cumbersome and not ideally sorted (bucket chains sorted reverse from what would be good). Normally this is not a big problem since those chains are short. > If there's an upcoming use of this RWL lock, then we should integrate it first and not bundle it with the client code. Certainly. I was not planning to do it right away, just voicing my support for this RWL idea. I have to look again at this anyway, maybe I'm overlooking something. E.g. I'm not sure if the MST needs to be functional beyond VMs normal lifetime. Then it is better to leave it lockless. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From duke at openjdk.org Thu Aug 25 13:06:01 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Thu, 25 Aug 2022 13:06:01 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v4] In-Reply-To: References: Message-ID: > May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? > > This PR does 3 things: > > * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot > * Adds some new utilities for writing multi-threaded tests. > * Adds some tests for MRSW Mutex using these new utilities > > The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 > > [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp Johan Sj?l?n has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Fix tests for updated threadHelper - Remove outdated threadHelper - Update documentation - Fix outdated headers and remove dead code - Review comments - Implement MRSWMutex ------------- Changes: https://git.openjdk.org/jdk/pull/9838/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9838&range=03 Stats: 355 lines in 3 files changed: 355 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9838.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9838/head:pull/9838 PR: https://git.openjdk.org/jdk/pull/9838 From duke at openjdk.org Thu Aug 25 13:06:02 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Thu, 25 Aug 2022 13:06:02 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v3] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 14:23:49 GMT, Johan Sj?l?n wrote: >> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? >> >> This PR does 3 things: >> >> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot >> * Adds some new utilities for writing multi-threaded tests. >> * Adds some tests for MRSW Mutex using these new utilities >> >> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 >> >> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > > Johan Sj?l?n has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. As no current review comments were alive I rebased onto master and force pushed. This reduces the PR a bit, as parts of it (additions to `threadHelper.inline.hpp`) was merged in another PR and as such could be removed. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From eosterlund at openjdk.org Thu Aug 25 14:32:31 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 25 Aug 2022 14:32:31 GMT Subject: RFR: 8292868: Explicitly pass a third temp register to MacroAssembler::store_heap_oop for aarch64 In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 10:11:30 GMT, Axel Boldt-Christmas wrote: > Currently G1 (and Shenandoah) implicitly uses r3 on aarch64 in store_at. > > This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). This would be fixed in the same way on aarch64 by passing the temporary register explicitly so it is part of the GC api > > Testing: Oracle aarch64 platforms tier 1-3 Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/10019 From mbaesken at openjdk.org Thu Aug 25 15:00:19 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 25 Aug 2022 15:00:19 GMT Subject: Integrated: JDK-8292903: enhance round_up_power_of_2 assertion output In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 08:20:49 GMT, Matthias Baesken wrote: > There is an assertion in round_up_power_of_2 for value <= max_power_of_2 of the type; would be nice to show the value of the problematic argument in case of failures. This pull request has now been integrated. Changeset: 8d3d4397 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/8d3d4397ccbfadab99fe572f0d0a8504d268a0dc Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8292903: enhance round_up_power_of_2 assertion output Reviewed-by: stefank, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/10016 From tschatzl at openjdk.org Thu Aug 25 15:57:25 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 25 Aug 2022 15:57:25 GMT Subject: RFR: 8292868: Explicitly pass a third temp register to MacroAssembler::store_heap_oop for aarch64 In-Reply-To: References: Message-ID: <7KwQtFF-Cze8L37wp3QH6eedzGI-nEW0krpfqq91eoI=.f64a6651-0656-4392-ac6f-a5c85c8c755c@github.com> On Thu, 25 Aug 2022 10:11:30 GMT, Axel Boldt-Christmas wrote: > Currently G1 (and Shenandoah) implicitly uses r3 on aarch64 in store_at. > > This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). This would be fixed in the same way on aarch64 by passing the temporary register explicitly so it is part of the GC api > > Testing: Oracle aarch64 platforms tier 1-3 Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10019 From ccheung at openjdk.org Thu Aug 25 16:03:34 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 25 Aug 2022 16:03:34 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v2] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 06:18:36 GMT, Ioi Lam wrote: >> Some CDS functions are always compiled, even when CDS is not enabled (e.g., for the minimal VM). >> >> This RFE puts some of the obvious ones inside `#if INCLUDE_CDS` blocks. >> >> Note: my goal is not to make the minimal VM as small as possible. But rather, I don't want to put `#if INCLUDE_CDS` inside each of those functions that access a CDS-only feature. (E.g., `ConstantPoolCache::save_for_archive`, which accesses `_initial_entries`, which is declared only when CDS is enabled). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @calvinccheung comments Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10010 From ccheung at openjdk.org Thu Aug 25 16:03:36 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 25 Aug 2022 16:03:36 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v2] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 06:14:40 GMT, Ioi Lam wrote: >> src/hotspot/share/oops/method.cpp line 404: >> >>> 402: } >>> 403: >>> 404: #if INCLUDE_CDS >> >> Do you need to ifdef out the declaration in method.hpp? > > Fixed. I also found out that `Method::restore_unshareable_info` also needed to be ifdef'ed out. Updates look good. ------------- PR: https://git.openjdk.org/jdk/pull/10010 From shade at openjdk.org Thu Aug 25 16:20:49 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 25 Aug 2022 16:20:49 GMT Subject: RFR: 8292867: RISC-V: Simplify weak CAS return value handling In-Reply-To: References: Message-ID: <9_tINd4COyXU236RaTZ8OvfYEyedUPXUgxyaytBNEz8=.86dd88e0-7e1b-4189-96c4-cd6cd1b61329@github.com> On Wed, 24 Aug 2022 19:23:29 GMT, Aleksey Shipilev wrote: > I see that current weak CAS implementations in `macroAssembler_riscv.cpp` return `0` on success, and then invert it in `riscv.ad` to match the Java's `boolean` result. I think we can just return the final value from `MacroAssembler`. > > Additional testing: > - [x] Linux RISC-V fastdebug `java/lang/invoke/VarHandles/` > - [x] Linux RISC-V fastdebug `compiler/unsafe` Testing is clean, many (all?) potential reviewers from RISC-V land have reviewed, so I am integrating. ------------- PR: https://git.openjdk.org/jdk/pull/10006 From shade at openjdk.org Thu Aug 25 16:28:06 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 25 Aug 2022 16:28:06 GMT Subject: Integrated: 8292867: RISC-V: Simplify weak CAS return value handling In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 19:23:29 GMT, Aleksey Shipilev wrote: > I see that current weak CAS implementations in `macroAssembler_riscv.cpp` return `0` on success, and then invert it in `riscv.ad` to match the Java's `boolean` result. I think we can just return the final value from `MacroAssembler`. > > Additional testing: > - [x] Linux RISC-V fastdebug `java/lang/invoke/VarHandles/` > - [x] Linux RISC-V fastdebug `compiler/unsafe` This pull request has now been integrated. Changeset: f57d3424 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/f57d34242c9b47936d137589fc75ab794d39a9d1 Stats: 39 lines in 2 files changed: 2 ins; 13 del; 24 mod 8292867: RISC-V: Simplify weak CAS return value handling Reviewed-by: yadongwang, fyang ------------- PR: https://git.openjdk.org/jdk/pull/10006 From vlivanov at openjdk.org Thu Aug 25 16:41:38 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 25 Aug 2022 16:41:38 GMT Subject: RFR: 8292203: AArch64: Represent Registers as values [v5] In-Reply-To: References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> Message-ID: On Wed, 24 Aug 2022 03:48:17 GMT, Vladimir Ivanov wrote: >> (It's a PR dependent on #9815.) >> >> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation. >> >> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types. >> >> Proposed change hides pointer representation behind value class. >> >> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). >> >> Code quality improves: >> GCC: https://godbolt.org/z/r6G36facj >> Clang: https://godbolt.org/z/x5oPdYEPM >> >> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) >> >> Testing: hs-tier1 - hs-tier5 >> >> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into rwrapper.aarch64 > - Merge branch 'master' into rwrapper.aarch64 > - explicit constructors > - Merge branch 'master' into rwrapper.aarch64 > - 8292203: AArch64: Represent Registers as values > - cleanups > - x86: Register class wrappers Thanks for the review, Andrew. ------------- PR: https://git.openjdk.org/jdk/pull/9826 From vlivanov at openjdk.org Thu Aug 25 16:55:37 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 25 Aug 2022 16:55:37 GMT Subject: Integrated: 8292203: AArch64: Represent Registers as values In-Reply-To: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com> Message-ID: On Wed, 10 Aug 2022 21:44:50 GMT, Vladimir Ivanov wrote: > (It's a PR dependent on #9815.) > > Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation. > > The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types. > > Proposed change hides pointer representation behind value class. > > Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code). > > Code quality improves: > GCC: https://godbolt.org/z/r6G36facj > Clang: https://godbolt.org/z/x5oPdYEPM > > (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.) > > Testing: hs-tier1 - hs-tier5 > > PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability. This pull request has now been integrated. Changeset: 2fe0ce01 Author: Vladimir Ivanov URL: https://git.openjdk.org/jdk/commit/2fe0ce01485d7b84dc109d3d4f24bdd908c0e7cf Stats: 527 lines in 15 files changed: 121 ins; 53 del; 353 mod 8292203: AArch64: Represent Registers as values Reviewed-by: kvn, aph ------------- PR: https://git.openjdk.org/jdk/pull/9826 From vlivanov at openjdk.org Thu Aug 25 17:44:17 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 25 Aug 2022 17:44:17 GMT Subject: RFR: 8292878: x86: Make scratch register usage explicit in assembler code [v2] In-Reply-To: References: Message-ID: > Improve MacroAssembler API and make scratch register usages explicit at use sites. > > Different parts of JVM have different assumptions about scratch registers and > implicit assumptions in MacroAssembler makes it harder to reason about the > correctness of generated code. > > Most of scratch register usages relate to `AddressLiteral` on x86_64. In such case the argument is turned into a default one (with `noreg` as a default) and implementation asserts that scratch register should be provided when the address is not guaranteed to be always reachable. > > Otherwise, scratch register argument is required to be explicitly provided. > > The only case left (mostly) intact is `call(AddressLiteral)`, but I switched it from `rscratch` (`r10`) to `rax`. > > Testing: > - [x] hs-tier1 - hs-tier4 (w/ -XX:+-ForceUnreachable) > - [x] x86_32 build Vladimir Ivanov has updated the pull request incrementally with two additional commits since the last revision: - ptrs_base_addr - cmpptr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10003/files - new: https://git.openjdk.org/jdk/pull/10003/files/f2911037..2b0565ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10003&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10003&range=00-01 Stats: 20 lines in 7 files changed: 9 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10003.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10003/head:pull/10003 PR: https://git.openjdk.org/jdk/pull/10003 From vlivanov at openjdk.org Thu Aug 25 18:18:05 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 25 Aug 2022 18:18:05 GMT Subject: RFR: 8292878: x86: Make scratch register usage explicit in assembler code [v3] In-Reply-To: References: Message-ID: > Improve MacroAssembler API and make scratch register usages explicit at use sites. > > Different parts of JVM have different assumptions about scratch registers and > implicit assumptions in MacroAssembler makes it harder to reason about the > correctness of generated code. > > Most of scratch register usages relate to `AddressLiteral` on x86_64. In such case the argument is turned into a default one (with `noreg` as a default) and implementation asserts that scratch register should be provided when the address is not guaranteed to be always reachable. > > Otherwise, scratch register argument is required to be explicitly provided. > > The only case left (mostly) intact is `call(AddressLiteral)`, but I switched it from `rscratch` (`r10`) to `rax`. > > Testing: > - [x] hs-tier1 - hs-tier4 (w/ -XX:+-ForceUnreachable) > - [x] x86_32 build Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: cast ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10003/files - new: https://git.openjdk.org/jdk/pull/10003/files/2b0565ef..ed4dc939 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10003&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10003&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10003.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10003/head:pull/10003 PR: https://git.openjdk.org/jdk/pull/10003 From vlivanov at openjdk.org Thu Aug 25 18:18:07 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 25 Aug 2022 18:18:07 GMT Subject: RFR: 8292878: x86: Make scratch register usage explicit in assembler code [v2] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 17:44:17 GMT, Vladimir Ivanov wrote: >> Improve MacroAssembler API and make scratch register usages explicit at use sites. >> >> Different parts of JVM have different assumptions about scratch registers and >> implicit assumptions in MacroAssembler makes it harder to reason about the >> correctness of generated code. >> >> Most of scratch register usages relate to `AddressLiteral` on x86_64. In such case the argument is turned into a default one (with `noreg` as a default) and implementation asserts that scratch register should be provided when the address is not guaranteed to be always reachable. >> >> Otherwise, scratch register argument is required to be explicitly provided. >> >> The only case left (mostly) intact is `call(AddressLiteral)`, but I switched it from `rscratch` (`r10`) to `rax`. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 (w/ -XX:+-ForceUnreachable) >> - [x] x86_32 build > > Vladimir Ivanov has updated the pull request incrementally with two additional commits since the last revision: > > - ptrs_base_addr > - cmpptr Accidentally, introduced a bug by turning some `AddressLiteral`s into rvals. Reverted relevant chanages, plus made the scratch register argument required for `cmpptr(Address,AddressLiteral,Register)`. Improved `Assembler::reachable`/`Assembler::always_reachable` to properly handle lvals. Also, applied a minor refactoring around `CompressedOops::ptrs_base_addr()`. ------------- PR: https://git.openjdk.org/jdk/pull/10003 From kvn at openjdk.org Thu Aug 25 18:27:16 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 25 Aug 2022 18:27:16 GMT Subject: RFR: 8292878: x86: Make scratch register usage explicit in assembler code [v3] In-Reply-To: References: Message-ID: <3DfSspS5zfnqm1DL1gxkKPNMZbD1YbutQRvOXxEi1qo=.80f650ad-fee3-4462-a8b8-610816c18b39@github.com> On Thu, 25 Aug 2022 18:18:05 GMT, Vladimir Ivanov wrote: >> Improve MacroAssembler API and make scratch register usages explicit at use sites. >> >> Different parts of JVM have different assumptions about scratch registers and >> implicit assumptions in MacroAssembler makes it harder to reason about the >> correctness of generated code. >> >> Most of scratch register usages relate to `AddressLiteral` on x86_64. In such case the argument is turned into a default one (with `noreg` as a default) and implementation asserts that scratch register should be provided when the address is not guaranteed to be always reachable. >> >> Otherwise, scratch register argument is required to be explicitly provided. >> >> The only case left (mostly) intact is `call(AddressLiteral)`, but I switched it from `rscratch` (`r10`) to `rax`. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 (w/ -XX:+-ForceUnreachable) >> - [x] x86_32 build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > cast Still good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10003 From hseigel at openjdk.org Thu Aug 25 18:29:00 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Thu, 25 Aug 2022 18:29:00 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v5] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 18:10:26 GMT, Coleen Phillimore wrote: >> This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. >> >> Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. >> I added a test for printing dictionary statistics. >> >> This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Review comments. Looks good! Thanks, Harold src/hotspot/share/runtime/deoptimization.cpp line 962: > 960: protected: > 961: static InstanceKlass* find_cache_klass(Thread* thread, Symbol* klass_name) { > 962: ResourceMark rm; Is worth adding rm(thread) in line 962? ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.org/jdk/pull/9886 From coleenp at openjdk.org Thu Aug 25 18:53:53 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 25 Aug 2022 18:53:53 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v5] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 18:26:01 GMT, Harold Seigel wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments. > > src/hotspot/share/runtime/deoptimization.cpp line 962: > >> 960: protected: >> 961: static InstanceKlass* find_cache_klass(Thread* thread, Symbol* klass_name) { >> 962: ResourceMark rm; > > Is worth adding rm(thread) in line 962? Yes, that's a good suggestion since we have thread. ------------- PR: https://git.openjdk.org/jdk/pull/9886 From jbhateja at openjdk.org Thu Aug 25 19:06:54 2022 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 25 Aug 2022 19:06:54 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v2] In-Reply-To: References: Message-ID: > Hi, > > This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. > A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8291649: Review comments resolutions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9987/files - new: https://git.openjdk.org/jdk/pull/9987/files/6d6e29b4..369bbd7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9987&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9987&range=00-01 Stats: 43 lines in 2 files changed: 12 ins; 3 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/9987.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9987/head:pull/9987 PR: https://git.openjdk.org/jdk/pull/9987 From jbhateja at openjdk.org Thu Aug 25 19:06:56 2022 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 25 Aug 2022 19:06:56 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v2] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 18:27:34 GMT, Vladimir Kozlov wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8291649: Review comments resolutions. > > I got failures in my testing. I posted them in bug report. Hi @vnkozlov , @kimbarrett , @schlosna , your comments addressed. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From coleenp at openjdk.org Thu Aug 25 19:07:46 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 25 Aug 2022 19:07:46 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v6] In-Reply-To: References: Message-ID: > This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. > > Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. > I added a test for printing dictionary statistics. > > This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add thread to ResourceMark. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9886/files - new: https://git.openjdk.org/jdk/pull/9886/files/76451771..a14cf6b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9886&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9886&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9886.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9886/head:pull/9886 PR: https://git.openjdk.org/jdk/pull/9886 From coleenp at openjdk.org Thu Aug 25 19:07:49 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 25 Aug 2022 19:07:49 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v5] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 18:10:26 GMT, Coleen Phillimore wrote: >> This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. >> >> Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. >> I added a test for printing dictionary statistics. >> >> This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Review comments. Thanks Robbin, Johan and Harold for the code reviews! ------------- PR: https://git.openjdk.org/jdk/pull/9886 From coleenp at openjdk.org Thu Aug 25 19:07:50 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 25 Aug 2022 19:07:50 GMT Subject: Integrated: 8292680: Convert Dictionary to ConcurrentHashTable In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 02:35:02 GMT, Coleen Phillimore wrote: > This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. > > Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. > I added a test for printing dictionary statistics. > > This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. This pull request has now been integrated. Changeset: 4f50316a Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/4f50316a1a985cd06af7eed158d7e1917b86d159 Stats: 620 lines in 30 files changed: 264 ins; 184 del; 172 mod 8292680: Convert Dictionary to ConcurrentHashTable Reviewed-by: rehn, hseigel ------------- PR: https://git.openjdk.org/jdk/pull/9886 From iklam at openjdk.org Thu Aug 25 19:12:56 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 25 Aug 2022 19:12:56 GMT Subject: RFR: 8292890: Remove PrintTouchedMethodsAtExit and LogTouchedMethods In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 22:27:30 GMT, Coleen Phillimore wrote: > These options were implemented for a CDS feature to move methods in the shared region, but was never used. I noticed them in converting rogue ad-hoc hashtables to ResourceHashtable. The Hashtable for touched methods keeps all methods referred to in a giant hashtable, and keeps the Symbols for the name, class and signature from being deleted by incrementing the refcounts. > This should just be removed since it's not used, and in the future if we needed this, we would implement it differently. > Testing with tier1 on Oracle platforms, tier1-3 on linux-x64-debug, linux-x64, windows-x64-debug, and other platforms builds-only. In progress. LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/10009 From stefank at openjdk.org Thu Aug 25 19:30:02 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 25 Aug 2022 19:30:02 GMT Subject: RFR: 8292921: Rewrite object field printer [v2] In-Reply-To: References: Message-ID: > See this as a RFC rather than a fully ready PR: > > fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. > > This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) > > and with the suggested change we get: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) > > which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). > > I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. > > There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. > > A full example of the generated output: > > java.lang.Class > {0x00007ffc36801080} - klass: 'java/lang/Class' > - ---- fields (total size 26 words): > - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) > - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) > - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) > - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) > - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) > - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) > - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) > - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) > - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) > - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) > - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) > - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) > - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) > - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) > - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) > - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) > - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) > - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) > - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) > - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) > - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) > - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) > - signature: Ljava/lang/String; > - ---- static fields (2): > - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) > - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) > - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) > - private static final 'REPL' 'C' @200 65533 (0x0000fffd) > - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) > - static final 'LATIN1' 'B' @203 0 (0x00000000) > - static final 'UTF16' 'B' @204 1 (0x00000001) Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Print correct number of bits for small integer types ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10028/files - new: https://git.openjdk.org/jdk/pull/10028/files/2b9247ec..432af92e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10028&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10028&range=00-01 Stats: 16 lines in 2 files changed: 6 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10028.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10028/head:pull/10028 PR: https://git.openjdk.org/jdk/pull/10028 From stefank at openjdk.org Thu Aug 25 19:30:03 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 25 Aug 2022 19:30:03 GMT Subject: RFR: 8292921: Rewrite object field printer In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:27:12 GMT, Stefan Karlsson wrote: > See this as a RFC rather than a fully ready PR: > > fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. > > This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) > > and with the suggested change we get: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) > > which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). > > I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. > > There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. > > A full example of the generated output: > > java.lang.Class > {0x00007ffc36801080} - klass: 'java/lang/Class' > - ---- fields (total size 26 words): > - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) > - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) > - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) > - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) > - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) > - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) > - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) > - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) > - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) > - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) > - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) > - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) > - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) > - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) > - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) > - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) > - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) > - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) > - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) > - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) > - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) > - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) > - signature: Ljava/lang/String; > - ---- static fields (2): > - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) > - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) > - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) > - private static final 'REPL' 'C' @200 65533 (0x0000fffd) > - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) > - static final 'LATIN1' 'B' @203 0 (0x00000000) > - static final 'UTF16' 'B' @204 1 (0x00000001) I've uploaded a new version that limits the number of bits printed when printing smaller integer types: - ---- static fields (2): - private static final 'serialVersionUID' 'J' @120 -6849794470754667710 (0xa0f0a4387a3bb342) - static final 'COMPACT_STRINGS' 'Z' @130 false (0x00) - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @112 NULL (0x00000000) - private static final 'REPL' 'C' @128 65533 (0xfffd) - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @116 NULL (0x00000000) - static final 'LATIN1' 'B' @131 0 (0x00) - static final 'UTF16' 'B' @132 1 (0x01) ------------- PR: https://git.openjdk.org/jdk/pull/10028 From duke at openjdk.org Thu Aug 25 19:30:59 2022 From: duke at openjdk.org (duke) Date: Thu, 25 Aug 2022 19:30:59 GMT Subject: [jdk19] Withdrawn: 8289302: Restore CriticalJNINatives In-Reply-To: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com> References: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com> Message-ID: On Wed, 29 Jun 2022 12:10:35 GMT, Coleen Phillimore wrote: > This change restores the code in the JVM that implemented the internal JavaCritical or CriticalJNINatives functionality. Customers are using this feature and there's no replacement yet for it. > This change is a backout and merge of jDK-8258192: Obsolete the CriticalJNINatives flag. > This change also adds the deprecation message that was missed, which I checked is okay with the customer. > > Tested with tiers1-4. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk19/pull/90 From hseigel at openjdk.org Thu Aug 25 19:48:56 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Thu, 25 Aug 2022 19:48:56 GMT Subject: RFR: 8292890: Remove PrintTouchedMethodsAtExit and LogTouchedMethods In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 22:27:30 GMT, Coleen Phillimore wrote: > These options were implemented for a CDS feature to move methods in the shared region, but was never used. I noticed them in converting rogue ad-hoc hashtables to ResourceHashtable. The Hashtable for touched methods keeps all methods referred to in a giant hashtable, and keeps the Symbols for the name, class and signature from being deleted by incrementing the refcounts. > This should just be removed since it's not used, and in the future if we needed this, we would implement it differently. > Testing with tier1 on Oracle platforms, tier1-3 on linux-x64-debug, linux-x64, windows-x64-debug, and other platforms builds-only. In progress. Looks good! Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.org/jdk/pull/10009 From stefank at openjdk.org Thu Aug 25 19:59:57 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 25 Aug 2022 19:59:57 GMT Subject: RFR: 8292921: Rewrite object field printer [v3] In-Reply-To: References: Message-ID: > See this as a RFC rather than a fully ready PR: > > fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. > > This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) > > and with the suggested change we get: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) > > which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). > > I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. > > There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. > > A full example of the generated output: > > java.lang.Class > {0x00007ffc36801080} - klass: 'java/lang/Class' > - ---- fields (total size 26 words): > - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) > - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) > - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) > - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) > - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) > - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) > - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) > - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) > - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) > - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) > - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) > - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) > - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) > - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) > - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) > - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) > - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) > - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) > - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) > - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) > - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) > - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) > - signature: Ljava/lang/String; > - ---- static fields (2): > - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) > - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) > - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) > - private static final 'REPL' 'C' @200 65533 (0x0000fffd) > - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) > - static final 'LATIN1' 'B' @203 0 (0x00000000) > - static final 'UTF16' 'B' @204 1 (0x00000001) Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Fix macOS sensitivity to format specifier for jlong ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10028/files - new: https://git.openjdk.org/jdk/pull/10028/files/432af92e..0ffe7e25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10028&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10028&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10028.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10028/head:pull/10028 PR: https://git.openjdk.org/jdk/pull/10028 From jrose at openjdk.org Thu Aug 25 21:06:03 2022 From: jrose at openjdk.org (John R Rose) Date: Thu, 25 Aug 2022 21:06:03 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v2] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 05:02:13 GMT, Kim Barrett wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8291649: Review comments resolutions. > > src/hotspot/share/utilities/moveBits.hpp line 63: > >> 61: /***************************************************************************** >> 62: * GCC and compatible (including Clang) >> 63: *****************************************************************************/ > > Is it really worth the extra code to allow the use of the gcc builtins? Kim, is there a way to do this in less code? Seems to me that something like this could work: template T reverse_bytes(T x) { if (size == 1) return x; T alt8bs = (T)((uint64_t)-1 / 0xFFFF * 0xFF); // 0x00FF?00FF x = ((x & alt8bs) << 8) | (((uint64_t)x >> 8 & alt8bs); if (size == 2) return x; T alt16bs = (T)((uint64_t)-1 / 0xFFFFFFFFll * 0xFFFF); // 0x0000FFFF?0000FFFF ? } That is, one function bodies handles cases for 1/2/4/8 byte values. Could it be just a function template, with an explicit instantiation (overriding the general template) where it matches an intrinsic? ------------- PR: https://git.openjdk.org/jdk/pull/9987 From coleenp at openjdk.org Thu Aug 25 21:13:55 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 25 Aug 2022 21:13:55 GMT Subject: RFR: 8292890: Remove PrintTouchedMethodsAtExit and LogTouchedMethods In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 22:27:30 GMT, Coleen Phillimore wrote: > These options were implemented for a CDS feature to move methods in the shared region, but was never used. I noticed them in converting rogue ad-hoc hashtables to ResourceHashtable. The Hashtable for touched methods keeps all methods referred to in a giant hashtable, and keeps the Symbols for the name, class and signature from being deleted by incrementing the refcounts. > This should just be removed since it's not used, and in the future if we needed this, we would implement it differently. > Testing with tier1 on Oracle platforms, tier1-3 on linux-x64-debug, linux-x64, windows-x64-debug, and other platforms builds-only. In progress. Thanks Ioi and Harold! ------------- PR: https://git.openjdk.org/jdk/pull/10009 From coleenp at openjdk.org Thu Aug 25 21:15:16 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 25 Aug 2022 21:15:16 GMT Subject: Integrated: 8292890: Remove PrintTouchedMethodsAtExit and LogTouchedMethods In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 22:27:30 GMT, Coleen Phillimore wrote: > These options were implemented for a CDS feature to move methods in the shared region, but was never used. I noticed them in converting rogue ad-hoc hashtables to ResourceHashtable. The Hashtable for touched methods keeps all methods referred to in a giant hashtable, and keeps the Symbols for the name, class and signature from being deleted by incrementing the refcounts. > This should just be removed since it's not used, and in the future if we needed this, we would implement it differently. > Testing with tier1 on Oracle platforms, tier1-3 on linux-x64-debug, linux-x64, windows-x64-debug, and other platforms builds-only. In progress. This pull request has now been integrated. Changeset: e353b572 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/e353b572a54edbbf0df1f01afa36067500157603 Stats: 364 lines in 19 files changed: 0 ins; 350 del; 14 mod 8292890: Remove PrintTouchedMethodsAtExit and LogTouchedMethods Reviewed-by: iklam, hseigel ------------- PR: https://git.openjdk.org/jdk/pull/10009 From amenkov at openjdk.org Thu Aug 25 21:37:24 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 25 Aug 2022 21:37:24 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem Message-ID: The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) ------------- Commit messages: - one more tab - tabs - Fixed cached_class_file Changes: https://git.openjdk.org/jdk/pull/10032/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=00 Issue: https://bugs.openjdk.org/browse/JDK-7124710 Stats: 555 lines in 4 files changed: 539 ins; 8 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10032.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10032/head:pull/10032 PR: https://git.openjdk.org/jdk/pull/10032 From kbarrett at openjdk.org Thu Aug 25 21:46:03 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 25 Aug 2022 21:46:03 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v4] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 13:06:01 GMT, Johan Sj?l?n wrote: >> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? >> >> This PR does 3 things: >> >> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot >> * Adds some new utilities for writing multi-threaded tests. >> * Adds some tests for MRSW Mutex using these new utilities >> >> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 >> >> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > > Johan Sj?l?n has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Fix tests for updated threadHelper > - Remove outdated threadHelper > - Update documentation > - Fix outdated headers and remove dead code > - Review comments > - Implement MRSWMutex Changes requested by kbarrett (Reviewer). src/hotspot/share/utilities/readWriteLock.cpp line 32: > 30: #include "utilities/readWriteLock.hpp" > 31: > 32: void ReadWriteLock::read_lock(Thread *current) { Consider asserting `current` really is the current thread, both here and in `write_lock`. src/hotspot/share/utilities/readWriteLock.cpp line 32: > 30: #include "utilities/readWriteLock.hpp" > 31: > 32: void ReadWriteLock::read_lock(Thread *current) { The more common (though far from universal) style in HotSpot code cuddles the `*` punctuator with the type rather than the variable, i.e. `Thread* current`. src/hotspot/share/utilities/readWriteLock.cpp line 38: > 36: // Wait until unlocked by writer > 37: auto await = [&]() { > 38: Locker locker(&_mon); In Mutex lock/unlock/wait/&etc there are various validity checks on the state of the current thread. This is going directly to a PlatformMonitor, so not doing any of those checks even though they seem like they are relevant for safe usage checking. This also doesn't support the InFlightMutexRelease stuff - not sure whether that matters here or not. src/hotspot/share/utilities/readWriteLock.cpp line 42: > 40: _mon.wait(0); > 41: } > 42: }; Why is this a lambda rather than a (private) ordinary member function? There's a bunch of these. Use of lambda reduces the separation of the code from it's use, but that doesn't seem to me worth the additional clutter. I'd rather a well-named helper function here, esp. since in this case would be the same helper as used by write_lock. Call it await_write_unlock. Consider putting the thread-type handling in the helper too, keeping this function small. src/hotspot/share/utilities/readWriteLock.cpp line 64: > 62: void ReadWriteLock::read_unlock() { > 63: for (;;) { > 64: const int32_t count = Atomic::load_acquire(&_count); I think an invariant here is that count is never 0 or -1. Consider asserting that. src/hotspot/share/utilities/readWriteLock.cpp line 67: > 65: > 66: if (count > 0) { > 67: // No writer in progress, try to decrement reader count. s/in progress/pending/ src/hotspot/share/utilities/readWriteLock.cpp line 72: > 70: } > 71: } else { > 72: // Writer in progress, try to increment reader count. s/in progress/pending/ src/hotspot/share/utilities/readWriteLock.cpp line 81: > 79: if (count == -2) { > 80: Locker locker(&_mon); > 81: _mon.notify_all(); Unfortunately, this also wakes up all pending readers. I wonder if there's a way to avoid that by having two monitors (only having monitors and not bare condvars makes that harder). src/hotspot/share/utilities/readWriteLock.cpp line 87: > 85: return; > 86: } > 87: } I found the control structure of read_unlock, with the use of continue and eventual "fall through" to the exit, a bit confusing and requiring lining up or counting braces. I think something like this (totally untested, but intended to be equivalent except it should have comments) is easier to follow: void ReadWriteLock::read_unlock() { for (;;) { const int32_t count = Atomic::load_acquire(&_count); if (count > 0) { if (Atomic::cmpxchg(&_count, count, count - 1) == count) { break; } } else if (Atomic::cmpxchg(&_count, count, count + 1) == count) { if (count == -2) { Locker locker(&_mon); _mon.notify_all(); } break; } } } I had a similar reaction to read_lock and write_lock. src/hotspot/share/utilities/readWriteLock.cpp line 139: > 137: return; > 138: } > 139: } I was wondering why a lock for write doesn't hold the underlying PlatformMonitor across the scope of the mutex region. Something like this (completely untested) void ReadWriteLock::write_lock(Thread* current) { _mon.lock(); while (true) { const int32_t count = Atomic::load_acquire(&_count); if (count < 0) { // Some other writer is waiting for readers to complete. // Approx: // while (Atomic::load_acquire(&_count)) _mon.wait(); await_write_unlock(current); } else if (Atomic::cmpxchg(&_count, count, -(count + 1)) == count) { // Claimed the write slot, but there might be active readers. if (count != 0) { // Approx: // while (Atomic::load_acquire(&_count) != -1) _mon.wait(); await_no_active_readers(current); } return; // return still holding lock } // else failed to claim write ownership, so try again. } } void ReadWriteLock::write_unlock() { assert(Atomic::load(&_count) == -1, "invariant"); Atomic::release_store(&_count, (int32_t)0); _mon.notify_all(); _mon.unlock(); } This seems simpler to me. Am I missing something? And looking at this also makes me wonder if `_mon` can just be a normal HotSpot `Monitor`, which would resolve many of the questions and comments I've made that are mostly driven by the direct use of `PlatformMonitor`. src/hotspot/share/utilities/readWriteLock.hpp line 82: > 80: // > 81: volatile int32_t _count; > 82: This class should be noncopyable. Maybe it is implicitly so via the `PlatformMonitor` member, but would be better to be explicit. src/hotspot/share/utilities/readWriteLock.hpp line 89: > 87: } > 88: > 89: ~ReadWriteLock() { Use default destructor (either implicit or explicit) rather than empty body destructor. src/hotspot/share/utilities/readWriteLock.hpp line 97: > 95: void read_lock(Thread* current = Thread::current()); > 96: void read_unlock(); > 97: }; There should be RAII classes associated with locking for read and locking for write. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From coleenp at openjdk.org Thu Aug 25 22:06:59 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 25 Aug 2022 22:06:59 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v7] In-Reply-To: <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com> References: <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com> Message-ID: On Fri, 19 Aug 2022 10:25:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Add context active assert src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4157: > 4155: } > 4156: } > 4157: log_debug(redefine, class, nmethod)("Enqueued all nmethods for deopt"); This seems to do the opposite of encapsulating nmethod logic by exposing RedefineClasses to the interesting bits of CodeCache iteration. And details of deoptimization that redefine classes really has other things to worry about. I didn't realize you were doing this. I suppose it's better than a big #if JVMTI in codeCache.cpp. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From vlivanov at openjdk.org Thu Aug 25 22:19:14 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 25 Aug 2022 22:19:14 GMT Subject: RFR: 8292878: x86: Make scratch register usage explicit in assembler code [v4] In-Reply-To: References: Message-ID: <75euD5SuLprNP7TWtaG57I-ePW0vkSh77mo2qEarevI=.f012660b-febc-409c-99fd-731b482fb31b@github.com> > Improve MacroAssembler API and make scratch register usages explicit at use sites. > > Different parts of JVM have different assumptions about scratch registers and > implicit assumptions in MacroAssembler makes it harder to reason about the > correctness of generated code. > > Most of scratch register usages relate to `AddressLiteral` on x86_64. In such case the argument is turned into a default one (with `noreg` as a default) and implementation asserts that scratch register should be provided when the address is not guaranteed to be always reachable. > > Otherwise, scratch register argument is required to be explicitly provided. > > The only case left (mostly) intact is `call(AddressLiteral)`, but I switched it from `rscratch` (`r10`) to `rax`. > > Testing: > - [x] hs-tier1 - hs-tier4 (w/ -XX:+-ForceUnreachable) > - [x] x86_32 build Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: x86_32 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10003/files - new: https://git.openjdk.org/jdk/pull/10003/files/ed4dc939..f920a0fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10003&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10003&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10003.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10003/head:pull/10003 PR: https://git.openjdk.org/jdk/pull/10003 From coleenp at openjdk.org Thu Aug 25 22:22:59 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 25 Aug 2022 22:22:59 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v7] In-Reply-To: References: <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com> Message-ID: On Thu, 25 Aug 2022 22:04:47 GMT, Coleen Phillimore wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Add context active assert > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4157: > >> 4155: } >> 4156: } >> 4157: log_debug(redefine, class, nmethod)("Enqueued all nmethods for deopt"); > > This seems to do the opposite of encapsulating nmethod logic by exposing RedefineClasses to the interesting bits of CodeCache iteration. And details of deoptimization that redefine classes really has other things to worry about. I didn't realize you were doing this. I suppose it's better than a big #if JVMTI in codeCache.cpp. Maybe this is ok, but I want to look at it more. The reason these functions started out in codeCache is because they looked like other functions in codeCache. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From dholmes at openjdk.org Thu Aug 25 22:43:57 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 Aug 2022 22:43:57 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v3] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 13:02:59 GMT, Johan Sj?l?n wrote: >> Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update documentation >> - Fix outdated headers and remove dead code > > As no current review comments were alive I rebased onto master and force pushed. This reduces the PR a bit, as parts of it (additions to `threadHelper.inline.hpp`) was merged in another PR and as such could be removed. @jdksjolen please do not ever force push in a live PR. There is no need, you can just do your merge locally and then push the merge changesets. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From dholmes at openjdk.org Thu Aug 25 22:59:04 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 Aug 2022 22:59:04 GMT Subject: RFR: 8292680: Convert Dictionary to ConcurrentHashTable [v6] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 19:07:46 GMT, Coleen Phillimore wrote: >> This change converts the dictionaries per ClassLoaderData from Old Hashtable to ConcurrentHashTables. The CHT has a few extra fields (locks and such) but the Old Hashtable had TableRateStatistics so footprint is similar. The Dictionaries require lock-free lookups because we lookup classes that we've already loaded whenever their names appear in the source code, which is pretty much all the time. The Dictionaries retain the SystemDictionary_lock for writing. Locking for adding entries gates other things like compiler dependencies and placeholder operations and loader constraint checking. The one thing that we can do with the CHT is do a resize without going to a safepoint, so this can resize dictionaries during adding. There's a test for this. >> >> Entries in the dictionaries are never individually deleted. When the class loader for the ClassLoaderData holding the dictionary is unloaded, the entire dictionary is deleted. Note dictionary is an old name for hashtable of loaded classes. We're keeping that name. >> I added a test for printing dictionary statistics. >> >> This has been tested with tier1-7, with tier1 on all Oracle platforms. I've also performance tested this with our internal performance test suite with slight improvement but not statistically significant. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add thread to ResourceMark. src/hotspot/share/runtime/deoptimization.cpp line 961: > 959: class BoxCacheBase : public CHeapObj { > 960: protected: > 961: static InstanceKlass* find_cache_klass(Thread* thread, Symbol* klass_name) { For next time ... if `thread` is always the current thread it would be good to name it `current`. ------------- PR: https://git.openjdk.org/jdk/pull/9886 From dholmes at openjdk.org Thu Aug 25 23:29:00 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 Aug 2022 23:29:00 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v2] In-Reply-To: References: Message-ID: <97dYZh8CENO7EZbw7hGRF_0NG4aHsovAayLwPgjQrgM=.0f9b2d04-e4d6-43e8-951a-c14d7b912dfc@github.com> On Thu, 25 Aug 2022 06:18:36 GMT, Ioi Lam wrote: >> Some CDS functions are always compiled, even when CDS is not enabled (e.g., for the minimal VM). >> >> This RFE puts some of the obvious ones inside `#if INCLUDE_CDS` blocks. >> >> Note: my goal is not to make the minimal VM as small as possible. But rather, I don't want to put `#if INCLUDE_CDS` inside each of those functions that access a CDS-only feature. (E.g., `ConstantPoolCache::save_for_archive`, which accesses `_initial_entries`, which is declared only when CDS is enabled). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @calvinccheung comments This is a bit of a slippery slope. We have things like NOT_CDS_RETURN to avoid the need to use `ifdef INCLUDE_CDS` at the callsites. If you now ifdef the call sites you don't need NOT_CDS_RETURN. Conversely if you are still using NOT_CDS_RETURN then why didn't you ifdef the callsites? src/hotspot/share/oops/method.hpp line 138: > 136: > 137: void remove_unshareable_info() NOT_CDS_RETURN; > 138: void restore_unshareable_info(TRAPS) NOT_CDS_RETURN; Surely these should ifdef'd out not stubbed out? The callers of these should also be in INCLUDE_CDS blocks. ------------- PR: https://git.openjdk.org/jdk/pull/10010 From jrose at openjdk.org Thu Aug 25 23:51:01 2022 From: jrose at openjdk.org (John R Rose) Date: Thu, 25 Aug 2022 23:51:01 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v2] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 19:06:54 GMT, Jatin Bhateja wrote: >> Hi, >> >> This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. >> A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8291649: Review comments resolutions. I will post a new version of moveBits.hpp and its gtest shortly, if I can make a simpler version that seems to get good code. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From kbarrett at openjdk.org Fri Aug 26 01:04:03 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 26 Aug 2022 01:04:03 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v2] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 19:06:54 GMT, Jatin Bhateja wrote: >> Hi, >> >> This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. >> A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8291649: Review comments resolutions. Changes requested by kbarrett (Reviewer). src/hotspot/share/utilities/moveBits.hpp line 30: > 28: #include "utilities/debug.hpp" > 29: #include "utilities/globalDefinitions.hpp" > 30: I think everything here should be constexpr. src/hotspot/share/utilities/moveBits.hpp line 31: > 29: #include "utilities/globalDefinitions.hpp" > 30: > 31: inline uint32_t reverse_bits_in_bytes_int(uint32_t x) { Instead of two functions with different names (suffixed `_int` and `_long`), have one function name that has two overloads disambiguated by the size of the argument, e.g. template constexpr T reverse_bits_in_bytes(T x) { ... } template constexpr T reverse_bits_in_bytes(T x) { ... } This allows `reverse_bits` to look something like template::value)> constexpr T reverse_bits(T v) { return reverse_bytes(reverse_bits_in_bytes(v)); } src/hotspot/share/utilities/moveBits.hpp line 36: > 34: x = (x & 0x33333333) << 2 | (x & 0xCCCCCCCC) >> 2; > 35: x = (x & 0x0F0F0F0F) << 4 | (x & 0xF0F0F0F0) >> 4; > 36: return x; You missed the point. Hacker's Delight (and seander) use shift-and-mask on one side of the bit-or and mask-and-shift on the other so the same constant is used on both sides. See https://graphics.stanford.edu/~seander/bithacks.html#ReverseParallel Similarly in the byte swappers. src/hotspot/share/utilities/moveBits.hpp line 102: > 100: static T doit(T v) { > 101: v = reverse_bits_in_bytes_int(v); > 102: return reverse_bytes_int(r, 16); I think the use of reverse_bytes_int is wrong here. src/hotspot/share/utilities/moveBits.hpp line 108: > 106: template struct ReverseBitsImpl { > 107: static T doit(T v) { > 108: v = reverse_bits_in_bytes(v); I don't see this function. Similarly in the size==8 case. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From jrose at openjdk.org Fri Aug 26 01:09:10 2022 From: jrose at openjdk.org (John R Rose) Date: Fri, 26 Aug 2022 01:09:10 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v2] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 00:44:21 GMT, Kim Barrett wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8291649: Review comments resolutions. > > src/hotspot/share/utilities/moveBits.hpp line 31: > >> 29: #include "utilities/globalDefinitions.hpp" >> 30: >> 31: inline uint32_t reverse_bits_in_bytes_int(uint32_t x) { > > Instead of two functions with different names (suffixed `_int` and `_long`), have one function name that has two overloads disambiguated by the size of the argument, e.g. > > > template > constexpr T reverse_bits_in_bytes(T x) { ... } > > template > constexpr T reverse_bits_in_bytes(T x) { ... } > > > This allows `reverse_bits` to look something like > > > template::value)> > constexpr T reverse_bits(T v) { > return reverse_bytes(reverse_bits_in_bytes(v)); > } Yes, that could work. This also works, and feels appropriately short + sweet to me: https://github.com/rose00/jdk/pull/new/moveBits (I also added a 90+% level gtest.) ------------- PR: https://git.openjdk.org/jdk/pull/9987 From dholmes at openjdk.org Fri Aug 26 01:58:59 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 26 Aug 2022 01:58:59 GMT Subject: RFR: 8292921: Rewrite object field printer [v3] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 19:59:57 GMT, Stefan Karlsson wrote: >> See this as a RFC rather than a fully ready PR: >> >> fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. >> >> This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) >> >> and with the suggested change we get: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) >> >> which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). >> >> I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. >> >> There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. >> >> A full example of the generated output: >> >> java.lang.Class >> {0x00007ffc36801080} - klass: 'java/lang/Class' >> - ---- fields (total size 26 words): >> - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) >> - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) >> - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) >> - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) >> - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) >> - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) >> - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) >> - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) >> - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) >> - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) >> - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) >> - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) >> - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) >> - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) >> - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) >> - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) >> - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) >> - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) >> - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) >> - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) >> - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) >> - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) >> - signature: Ljava/lang/String; >> - ---- static fields (2): >> - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) >> - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) >> - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) >> - private static final 'REPL' 'C' @200 65533 (0x0000fffd) >> - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) >> - static final 'LATIN1' 'B' @203 0 (0x00000000) >> - static final 'UTF16' 'B' @204 1 (0x00000001) > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Fix macOS sensitivity to format specifier for jlong I think this looks fine in principle. A couple of queries/suggestions below. Thanks src/hotspot/share/runtime/fieldDescriptor.cpp line 211: > 209: } > 210: > 211: // Print a hint as to the underlying integer representation. Nit: double space src/hotspot/share/runtime/fieldDescriptor.cpp line 227: > 225: } else { > 226: switch (ft) { > 227: case T_BYTE: st->print(" (" PTR8_FORMAT ")", obj->byte_field(offset())); break; Suggestion: INT8_FORMAT_X as this is not a PTR Ditto for 16, 32, and 64. src/hotspot/share/runtime/fieldDescriptor.cpp line 230: > 228: case T_CHAR: st->print(" (" PTR16_FORMAT ")", obj->char_field(offset())); break; > 229: case T_FLOAT: st->print(" (" PTR32_FORMAT ")", obj->int_field(offset())); break; > 230: case T_INT: st->print(" (" PTR32_FORMAT ")", obj->int_field(offset())); break; Should these be collapsed into one case, as implicitly done for long/double? ------------- PR: https://git.openjdk.org/jdk/pull/10028 From fjiang at openjdk.org Fri Aug 26 02:49:17 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Fri, 26 Aug 2022 02:49:17 GMT Subject: RFR: 8292575: riscv: Represent Registers as values [v2] In-Reply-To: References: Message-ID: > Follow up [JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153) and [JDK-8292203](https://bugs.openjdk.org/browse/JDK-8292203), migrate away from pointer-based representation of Register values. > > It improves compile-time checking by forbidding implicit conversions between integrals and pointers. > > Testing: > - hotspot/jdk tier1 on unmatched board > - hotspot/jdk tier1 on qemu Feilong Jiang 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' of https://github.com/openjdk/jdk into riscv-register-rep - Represent Registers as values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9936/files - new: https://git.openjdk.org/jdk/pull/9936/files/3a126f1e..72e55d46 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9936&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9936&range=00-01 Stats: 21803 lines in 643 files changed: 8464 ins; 10027 del; 3312 mod Patch: https://git.openjdk.org/jdk/pull/9936.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9936/head:pull/9936 PR: https://git.openjdk.org/jdk/pull/9936 From dlong at openjdk.org Fri Aug 26 03:16:17 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 26 Aug 2022 03:16:17 GMT Subject: RFR: 8292694: x86_64 c2i/i2c adapters may use more stack space than necessary Message-ID: The c2i adapter includes the return address in the alignment calculation, making %rsp aligned instead of %rsp+8. The i2c adapter aligns "extrawords" even though %rsp is aligned later, and the incoming stack is not guaranteed to be aligned. ------------- Commit messages: - fix c2i and i2c stack alignment Changes: https://git.openjdk.org/jdk/pull/10034/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10034&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292694 Stats: 86 lines in 4 files changed: 51 ins; 25 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10034/head:pull/10034 PR: https://git.openjdk.org/jdk/pull/10034 From iklam at openjdk.org Fri Aug 26 04:45:32 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 26 Aug 2022 04:45:32 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v3] In-Reply-To: References: Message-ID: > Some CDS functions are always compiled, even when CDS is not enabled (e.g., for the minimal VM). > > This RFE puts some of the obvious ones inside `#if INCLUDE_CDS` blocks. > > Note: my goal is not to make the minimal VM as small as possible. But rather, I don't want to put `#if INCLUDE_CDS` inside each of those functions that access a CDS-only feature. (E.g., `ConstantPoolCache::save_for_archive`, which accesses `_initial_entries`, which is declared only when CDS is enabled). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @dholmes-ora and @coleenp comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10010/files - new: https://git.openjdk.org/jdk/pull/10010/files/9941eb7e..17a20bde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10010&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10010&range=01-02 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10010.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10010/head:pull/10010 PR: https://git.openjdk.org/jdk/pull/10010 From iklam at openjdk.org Fri Aug 26 04:45:33 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 26 Aug 2022 04:45:33 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v2] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 11:42:25 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @calvinccheung comments > > src/hotspot/share/oops/klass.hpp line 575: > >> 573: } >> 574: } >> 575: #endif > > Can you add an // INCLUDE_CDS here? If they're more than 10 lines apart, uncommented endifs can be really confusing. This one is sort of borderline far away. Thanks. Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/10010 From iklam at openjdk.org Fri Aug 26 04:45:33 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 26 Aug 2022 04:45:33 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v2] In-Reply-To: <97dYZh8CENO7EZbw7hGRF_0NG4aHsovAayLwPgjQrgM=.0f9b2d04-e4d6-43e8-951a-c14d7b912dfc@github.com> References: <97dYZh8CENO7EZbw7hGRF_0NG4aHsovAayLwPgjQrgM=.0f9b2d04-e4d6-43e8-951a-c14d7b912dfc@github.com> Message-ID: On Thu, 25 Aug 2022 23:23:01 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @calvinccheung comments > > src/hotspot/share/oops/method.hpp line 138: > >> 136: >> 137: void remove_unshareable_info() NOT_CDS_RETURN; >> 138: void restore_unshareable_info(TRAPS) NOT_CDS_RETURN; > > Surely these should ifdef'd out not stubbed out? The callers of these should also be in INCLUDE_CDS blocks. Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/10010 From iklam at openjdk.org Fri Aug 26 04:49:15 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 26 Aug 2022 04:49:15 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v4] In-Reply-To: References: Message-ID: > Some CDS functions are always compiled, even when CDS is not enabled (e.g., for the minimal VM). > > This RFE puts some of the obvious ones inside `#if INCLUDE_CDS` blocks. > > Note: my goal is not to make the minimal VM as small as possible. But rather, I don't want to put `#if INCLUDE_CDS` inside each of those functions that access a CDS-only feature. (E.g., `ConstantPoolCache::save_for_archive`, which accesses `_initial_entries`, which is declared only when CDS is enabled). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10010/files - new: https://git.openjdk.org/jdk/pull/10010/files/17a20bde..5f8bcd39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10010&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10010&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10010.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10010/head:pull/10010 PR: https://git.openjdk.org/jdk/pull/10010 From stuefe at openjdk.org Fri Aug 26 05:16:57 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 26 Aug 2022 05:16:57 GMT Subject: RFR: 8292921: Rewrite object field printer [v3] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 19:59:57 GMT, Stefan Karlsson wrote: >> See this as a RFC rather than a fully ready PR: >> >> fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. >> >> This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) >> >> and with the suggested change we get: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) >> >> which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). >> >> I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. >> >> There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. >> >> A full example of the generated output: >> >> java.lang.Class >> {0x00007ffc36801080} - klass: 'java/lang/Class' >> - ---- fields (total size 26 words): >> - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) >> - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) >> - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) >> - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) >> - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) >> - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) >> - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) >> - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) >> - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) >> - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) >> - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) >> - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) >> - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) >> - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) >> - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) >> - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) >> - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) >> - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) >> - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) >> - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) >> - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) >> - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) >> - signature: Ljava/lang/String; >> - ---- static fields (2): >> - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) >> - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) >> - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) >> - private static final 'REPL' 'C' @200 65533 (0x0000fffd) >> - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) >> - static final 'LATIN1' 'B' @203 0 (0x00000000) >> - static final 'UTF16' 'B' @204 1 (0x00000001) > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Fix macOS sensitivity to format specifier for jlong LGTM. Small nits inline, I leave it up to you though. src/hotspot/share/runtime/fieldDescriptor.cpp line 159: > 157: void fieldDescriptor::print_on_for(outputStream* st, oop obj) { > 158: print_on(st); > 159: nit: factor out printing of the leading space to before the switch? src/hotspot/share/utilities/globalDefinitions.hpp line 100: > 98: // Format 16-bit quantities. > 99: #define PTR16_FORMAT "0x%04" PRIx16 > 100: nit: I would find UINT(8|16)_FORMAT_X more logical. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/10028 From duke at openjdk.org Fri Aug 26 05:41:03 2022 From: duke at openjdk.org (Dingli Zhang) Date: Fri, 26 Aug 2022 05:41:03 GMT Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls In-Reply-To: References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com> Message-ID: <5MM0nQyHoWtAEbR2u-9wxKTFZvTyt6AhS42pvOb_mes=.b52c6a36-d58c-4f01-966f-0bd18c09d2c0@github.com> On Wed, 17 Aug 2022 12:09:05 GMT, Evgeny Astigeevich wrote: >> Hi Andrew(@theRealAph), >> Your comments are usually highly useful and help to identify missed issues. >> Do you have any of them? >> Thanks, >> Evgeny > >> Hi @eastig , I'd like to ask you how to get the experiment results, aka. `Saved bytes`, `Nmethods with shared stubs`,`Final # of nmethods`. Thank you! > > You can get `Final # of nmethods` with `-XX:+PrintCodeCache`. > To get `Saved bytes`, `Nmethods with shared stubs` you need to instrument `emit_shared_stubs_to_interp` to count shared stubs and nmethods sharing them. Hi @eastig , I would like to recurring your experimental data and I would be very grateful if you could provide a small patch to help me get the result of `Saved bytes` and `Nmethods with shared stubs`. Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/8816 From dholmes at openjdk.org Fri Aug 26 06:00:56 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 26 Aug 2022 06:00:56 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v4] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 04:49:15 GMT, Ioi Lam wrote: >> Some CDS functions are always compiled, even when CDS is not enabled (e.g., for the minimal VM). >> >> This RFE puts some of the obvious ones inside `#if INCLUDE_CDS` blocks. >> >> Note: my goal is not to make the minimal VM as small as possible. But rather, I don't want to put `#if INCLUDE_CDS` inside each of those functions that access a CDS-only feature. (E.g., `ConstantPoolCache::save_for_archive`, which accesses `_initial_entries`, which is declared only when CDS is enabled). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo Thanks for the updates. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10010 From kbarrett at openjdk.org Fri Aug 26 06:39:18 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 26 Aug 2022 06:39:18 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v2] In-Reply-To: References: Message-ID: <55UCDLv71g3p2WruG3x2ihLvFAjtA1HTGHLod1uI-RY=.0295efe2-af4b-47d9-a68e-d2be1bb21af0@github.com> On Fri, 26 Aug 2022 01:06:25 GMT, John R Rose wrote: >> src/hotspot/share/utilities/moveBits.hpp line 31: >> >>> 29: #include "utilities/globalDefinitions.hpp" >>> 30: >>> 31: inline uint32_t reverse_bits_in_bytes_int(uint32_t x) { >> >> Instead of two functions with different names (suffixed `_int` and `_long`), have one function name that has two overloads disambiguated by the size of the argument, e.g. >> >> >> template >> constexpr T reverse_bits_in_bytes(T x) { ... } >> >> template >> constexpr T reverse_bits_in_bytes(T x) { ... } >> >> >> This allows `reverse_bits` to look something like >> >> >> template::value)> >> constexpr T reverse_bits(T v) { >> return reverse_bytes(reverse_bits_in_bytes(v)); >> } > > Yes, that could work. > > This also works, and feels appropriately short + sweet to me: > > https://github.com/rose00/jdk/pull/new/moveBits > > (I also added a 90+% level gtest.) > > (Sorry; amended with `constexpr` and force-pushed?) I took John's code and made various (I think) improvements: https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:reverse-bits?expand=1 >> src/hotspot/share/utilities/moveBits.hpp line 63: >> >>> 61: /***************************************************************************** >>> 62: * GCC and compatible (including Clang) >>> 63: *****************************************************************************/ >> >> Is it really worth the extra code to allow the use of the gcc builtins? > > Kim, is there a way to do this in less code? > > Seems to me that something like this could work: > > > template > T reverse_bytes(T x) { > if (size == 1) return x; > T alt8bs = (T)((uint64_t)-1 / 0xFFFF * 0xFF); // 0x00FF?00FF > x = ((x & alt8bs) << 8) | (((uint64_t)x >> 8 & alt8bs); > if (size == 2) return x; > T alt16bs = (T)((uint64_t)-1 / 0xFFFFFFFFll * 0xFFFF); // 0x0000FFFF?0000FFFF > ? > } > > > That is, one function bodies handles cases for 1/2/4/8 byte values. > > Could it be just a function template, with an explicit instantiation (overriding the general template) where it matches an intrinsic? Answering my own question, no, it's not worth the extra code. gcc (and likely other compilers) are quite good at recognizing byte swapping code and transforming it into the appropriate platform-specific code like x86 bswap. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From dlong at openjdk.org Fri Aug 26 07:01:57 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 26 Aug 2022 07:01:57 GMT Subject: RFR: 8292584: assert(cb != __null) failed: must be with -XX:-Inline [v5] In-Reply-To: References: Message-ID: > generate_Continuation_doYield_entry() creates an interpreter entry point, but jumps to a compiled stub, which needs to be walkable. The interpreter entry does not create an interpreter frame, so frame walking expects a compiled frame. Normally everything is OK, but if C1 does not inline the intrinsic and we get to the interpreter entry through the c2i adapter, then things can break if the c2i adapter padded the stack because of alignment. The easiest fix is to undo what the c2i adapter might have done. Dean Long has updated the pull request incrementally with one additional commit since the last revision: fix build failures ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9974/files - new: https://git.openjdk.org/jdk/pull/9974/files/8be3d321..db0e35b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9974&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9974&range=03-04 Stats: 52 lines in 8 files changed: 0 ins; 52 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9974.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9974/head:pull/9974 PR: https://git.openjdk.org/jdk/pull/9974 From john.r.rose at oracle.com Fri Aug 26 08:07:21 2022 From: john.r.rose at oracle.com (John Rose) Date: Fri, 26 Aug 2022 01:07:21 -0700 Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v2] In-Reply-To: <55UCDLv71g3p2WruG3x2ihLvFAjtA1HTGHLod1uI-RY=.0295efe2-af4b-47d9-a68e-d2be1bb21af0@github.com> References: <55UCDLv71g3p2WruG3x2ihLvFAjtA1HTGHLod1uI-RY=.0295efe2-af4b-47d9-a68e-d2be1bb21af0@github.com> Message-ID: <8ED40C4E-FB11-4B7E-89A2-AF8E0ED78816@oracle.com> Thanks; right. I like your improvements, except the metaprogramming. Here?s what I got: https://github.com/openjdk/jdk/compare/master...rose00:jdk:moveBits I?m not against metaprogramming when we need it, but there are alternatives here to deriving the extra types; the tricks are explained in the comments. I suppose it?s a matter of taste whether the metaprogramming is more or less obscure than the bit-twiddling tricks, but I will observe that bit-twiddling tricks are the focus of this file. I verified by hand that you get good code in all cases, even without explicit mentions of the intrinsics. Here?s an easy way to start that process: ``` $ make hotspot exploded-test TEST=gtest:moveBits $ objdump -D $(find build -name test_moveBits.o) > /tmp/foo $ sed < /tmp/foo -n /quality/,/stream/p | grep -B20 bswap ``` On 25 Aug 2022, at 23:39, Kim Barrett wrote: > On Fri, 26 Aug 2022 01:06:25 GMT, John R Rose > wrote: > >>> src/hotspot/share/utilities/moveBits.hpp line 31: >>> >>>> 29: #include "utilities/globalDefinitions.hpp" >>>> 30: >>>> 31: inline uint32_t reverse_bits_in_bytes_int(uint32_t x) { >>> >>> Instead of two functions with different names (suffixed `_int` and >>> `_long`), have one function name that has two overloads >>> disambiguated by the size of the argument, e.g. >>> >>> >>> template >>> constexpr T reverse_bits_in_bytes(T x) { ... } >>> >>> template >>> constexpr T reverse_bits_in_bytes(T x) { ... } >>> >>> >>> This allows `reverse_bits` to look something like >>> >>> >>> template::value)> >>> constexpr T reverse_bits(T v) { >>> return reverse_bytes(reverse_bits_in_bytes(v)); >>> } >> >> Yes, that could work. >> >> This also works, and feels appropriately short + sweet to me: >> >> https://github.com/rose00/jdk/pull/new/moveBits >> >> (I also added a 90+% level gtest.) >> >> (Sorry; amended with `constexpr` and force-pushed?) > > I took John's code and made various (I think) improvements: > https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:reverse-bits?expand=1 > >>> src/hotspot/share/utilities/moveBits.hpp line 63: >>> >>>> 61: >>>> /***************************************************************************** >>>> 62: * GCC and compatible (including Clang) >>>> 63: >>>> *****************************************************************************/ >>> >>> Is it really worth the extra code to allow the use of the gcc >>> builtins? >> >> Kim, is there a way to do this in less code? >> >> Seems to me that something like this could work: >> >> >> template >> T reverse_bytes(T x) { >> if (size == 1) return x; >> T alt8bs = (T)((uint64_t)-1 / 0xFFFF * 0xFF); // 0x00FF?00FF >> x = ((x & alt8bs) << 8) | (((uint64_t)x >> 8 & alt8bs); >> if (size == 2) return x; >> T alt16bs = (T)((uint64_t)-1 / 0xFFFFFFFFll * 0xFFFF); // >> 0x0000FFFF?0000FFFF >> ? >> } >> >> >> That is, one function bodies handles cases for 1/2/4/8 byte values. >> >> Could it be just a function template, with an explicit instantiation >> (overriding the general template) where it matches an intrinsic? > > Answering my own question, no, it's not worth the extra code. gcc > (and likely other compilers) are quite good at recognizing byte > swapping code and transforming it into the appropriate > platform-specific code like x86 bswap. > > ------------- > > PR: https://git.openjdk.org/jdk/pull/9987 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbhateja at openjdk.org Fri Aug 26 08:37:03 2022 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 26 Aug 2022 08:37:03 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v2] In-Reply-To: <55UCDLv71g3p2WruG3x2ihLvFAjtA1HTGHLod1uI-RY=.0295efe2-af4b-47d9-a68e-d2be1bb21af0@github.com> References: <55UCDLv71g3p2WruG3x2ihLvFAjtA1HTGHLod1uI-RY=.0295efe2-af4b-47d9-a68e-d2be1bb21af0@github.com> Message-ID: On Fri, 26 Aug 2022 06:36:59 GMT, Kim Barrett wrote: >> Yes, that could work. >> >> This also works, and feels appropriately short + sweet to me: >> >> https://github.com/rose00/jdk/pull/new/moveBits >> >> (I also added a 90+% level gtest.) >> >> (Sorry; amended with `constexpr` and force-pushed?) > > I took John's code and made various (I think) improvements: > https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:reverse-bits?expand=1 constexpr enables compiler to bypass usual in-lining constraints and inline the method body if all the arguments are constants at compile time under an assumption that IR pallet will be constant folded to a single value, in given context JIT compiler uses reverse_bit utility to constant fold Reverse IR node with constant inputs. Thus technically constexpr will not have much impact here. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From stefank at openjdk.org Fri Aug 26 08:38:38 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 08:38:38 GMT Subject: RFR: 8292921: Rewrite object field printer [v4] In-Reply-To: References: Message-ID: <-DEcS0BOP5dI3VafkjZSrQE4Te3Rkv7WM0IpvNE4SxY=.b73484d7-76fc-4ac3-a8d3-eeaee087e03b@github.com> > See this as a RFC rather than a fully ready PR: > > fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. > > This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) > > and with the suggested change we get: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) > > which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). > > I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. > > There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. > > A full example of the generated output: > > java.lang.Class > {0x00007ffc36801080} - klass: 'java/lang/Class' > - ---- fields (total size 26 words): > - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) > - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) > - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) > - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) > - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) > - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) > - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) > - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) > - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) > - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) > - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) > - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) > - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) > - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) > - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) > - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) > - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) > - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) > - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) > - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) > - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) > - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) > - signature: Ljava/lang/String; > - ---- static fields (2): > - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) > - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) > - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) > - private static final 'REPL' 'C' @200 65533 (0x0000fffd) > - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) > - static final 'LATIN1' 'B' @203 0 (0x00000000) > - static final 'UTF16' 'B' @204 1 (0x00000001) Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review dholmes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10028/files - new: https://git.openjdk.org/jdk/pull/10028/files/0ffe7e25..ef5e5bde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10028&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10028&range=02-03 Stats: 15 lines in 1 file changed: 0 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10028.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10028/head:pull/10028 PR: https://git.openjdk.org/jdk/pull/10028 From stefank at openjdk.org Fri Aug 26 08:38:41 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 08:38:41 GMT Subject: RFR: 8292921: Rewrite object field printer [v3] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 01:46:12 GMT, David Holmes wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix macOS sensitivity to format specifier for jlong > > src/hotspot/share/runtime/fieldDescriptor.cpp line 230: > >> 228: case T_CHAR: st->print(" (" PTR16_FORMAT ")", obj->char_field(offset())); break; >> 229: case T_FLOAT: st->print(" (" PTR32_FORMAT ")", obj->int_field(offset())); break; >> 230: case T_INT: st->print(" (" PTR32_FORMAT ")", obj->int_field(offset())); break; > > Should these be collapsed into one case, as implicitly done for long/double? I see your point. I think I prefer to change the long/double cases to look like the rest of the block of primitives. I think this gets easier to read if we remove that if/else. Take a look and see if you agree. ------------- PR: https://git.openjdk.org/jdk/pull/10028 From aboldtch at openjdk.org Fri Aug 26 08:41:34 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 26 Aug 2022 08:41:34 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v8] In-Reply-To: References: Message-ID: > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: - Add asserts and comments - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Add context active assert - Cleanup comment - Add list optimization - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Rename deoptimize_done enum value - Add missing code from list revert - Initial draft new terminology - Make _context_active atomic - ... and 18 more: https://git.openjdk.org/jdk/compare/054c23f4...11d9dd24 ------------- Changes: https://git.openjdk.org/jdk/pull/9655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=07 Stats: 753 lines in 27 files changed: 351 ins; 282 del; 120 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From stefank at openjdk.org Fri Aug 26 08:45:11 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 08:45:11 GMT Subject: RFR: 8292921: Rewrite object field printer [v3] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 01:54:12 GMT, David Holmes wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix macOS sensitivity to format specifier for jlong > > src/hotspot/share/runtime/fieldDescriptor.cpp line 227: > >> 225: } else { >> 226: switch (ft) { >> 227: case T_BYTE: st->print(" (" PTR8_FORMAT ")", obj->byte_field(offset())); break; > > Suggestion: INT8_FORMAT_X as this is not a PTR > > Ditto for 16, 32, and 64. I had the same thought first. However, if I use the INT/UINT versions that the output will be: `80041dc0` instead of `0x0000000080041dc0`. I prefer the latter, and that is probably a personal taste, but it also makes it a little less tedious to use in a debugger if 0x is already prepended. ------------- PR: https://git.openjdk.org/jdk/pull/10028 From stefank at openjdk.org Fri Aug 26 08:45:12 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 08:45:12 GMT Subject: RFR: 8292921: Rewrite object field printer [v3] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 08:39:21 GMT, Stefan Karlsson wrote: >> src/hotspot/share/runtime/fieldDescriptor.cpp line 227: >> >>> 225: } else { >>> 226: switch (ft) { >>> 227: case T_BYTE: st->print(" (" PTR8_FORMAT ")", obj->byte_field(offset())); break; >> >> Suggestion: INT8_FORMAT_X as this is not a PTR >> >> Ditto for 16, 32, and 64. > > I had the same thought first. However, if I use the INT/UINT versions that the output will be: `80041dc0` instead of `0x0000000080041dc0`. I prefer the latter, and that is probably a personal taste, but it also makes it a little less tedious to use in a debugger if 0x is already prepended. Maybe we can find a better name, that still prints the 0x00<...> format? I agree that these PTR32, PTR16, PTR8 is oddly named. Let me think about alternative names. ------------- PR: https://git.openjdk.org/jdk/pull/10028 From stefank at openjdk.org Fri Aug 26 08:45:13 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 08:45:13 GMT Subject: RFR: 8292921: Rewrite object field printer [v3] In-Reply-To: References: Message-ID: <8U55bHfIzG8oJIZVZWcRu56_34rOFvy24I1dSnTaCxo=.a32cac8d-e8b1-4250-839b-479454598e35@github.com> On Fri, 26 Aug 2022 05:09:13 GMT, Thomas Stuefe wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix macOS sensitivity to format specifier for jlong > > src/hotspot/share/utilities/globalDefinitions.hpp line 100: > >> 98: // Format 16-bit quantities. >> 99: #define PTR16_FORMAT "0x%04" PRIx16 >> 100: > > nit: I would find UINT(8|16)_FORMAT_X more logical. See my comments to David's comments. ------------- PR: https://git.openjdk.org/jdk/pull/10028 From stefank at openjdk.org Fri Aug 26 08:47:47 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 08:47:47 GMT Subject: RFR: 8292921: Rewrite object field printer [v5] In-Reply-To: References: Message-ID: <-LXLeyKLpCMhiqjSJ_q4RWiaupkoFtcRjC7HgTGGeF4=.bbc5bd6b-ef87-43fe-b439-b5fc52f7b247@github.com> > See this as a RFC rather than a fully ready PR: > > fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. > > This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) > > and with the suggested change we get: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) > > which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). > > I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. > > There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. > > A full example of the generated output: > > java.lang.Class > {0x00007ffc36801080} - klass: 'java/lang/Class' > - ---- fields (total size 26 words): > - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) > - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) > - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) > - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) > - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) > - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) > - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) > - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) > - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) > - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) > - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) > - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) > - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) > - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) > - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) > - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) > - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) > - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) > - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) > - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) > - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) > - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) > - signature: Ljava/lang/String; > - ---- static fields (2): > - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) > - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) > - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) > - private static final 'REPL' 'C' @200 65533 (0x0000fffd) > - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) > - static final 'LATIN1' 'B' @203 0 (0x00000000) > - static final 'UTF16' 'B' @204 1 (0x00000001) Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review tsteufe ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10028/files - new: https://git.openjdk.org/jdk/pull/10028/files/ef5e5bde..e1f05e4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10028&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10028&range=03-04 Stats: 11 lines in 1 file changed: 1 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10028.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10028/head:pull/10028 PR: https://git.openjdk.org/jdk/pull/10028 From chagedorn at openjdk.org Fri Aug 26 09:02:21 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 26 Aug 2022 09:02:21 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN [v2] In-Reply-To: <4-3rk63k1x5ElcfNiAN0iEWHFerxELQa1Gn3fDfzrTQ=.e3db4433-2c10-4803-a84b-5fcafc14f81e@github.com> References: <4-3rk63k1x5ElcfNiAN0iEWHFerxELQa1Gn3fDfzrTQ=.e3db4433-2c10-4803-a84b-5fcafc14f81e@github.com> Message-ID: On Thu, 25 Aug 2022 09:44:47 GMT, Pengfei Li wrote: >> Recently, an igvn infinite loop issue was reported. Git bisection shows >> it appears after our JDK-8289996 patch. But after that patch is backed >> out, we find similar test still fails. We have attached a jtreg case to >> reproduce this issue. >> >> The ideal graph of the problematic method has a `MulINode` multiplying a >> `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` >> moves the constant input to the right hand side. And `Ideal()` function >> in its parent class `MulNode` has the similar logic. In some code paths, >> `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, >> `MulINode` and `MulNode` use different ways to check constant. One calls >> `type->singleton()` and the other calls `node->find_int_con(val)` which >> accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` >> can be evaluated to a constant, the two inputs of the `MulNode` will be >> swapped back and forth in `Ideal()` calls. It eventually causes the igvn >> infinite loop issue. >> >> This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` >> because it's enough to do this by calling `MulNode::Ideal()`. We also do >> some code cleanup in this patch as we have done in JDK-8289996. >> >> Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. > > Pengfei Li has updated the pull request incrementally with one additional commit since the last revision: > > Reword some comments src/hotspot/share/opto/mulnode.cpp line 252: > 250: // As the if block above tests the result of find_int_con(0), which > 251: // is zero if no constant is found, we cannot have "con == 0" here. > 252: if (con == 1) return NULL; // By one is handled by Identity call While at it, you could add braces here. Same further down for `MulL`. ------------- PR: https://git.openjdk.org/jdk/pull/9820 From chagedorn at openjdk.org Fri Aug 26 09:02:21 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 26 Aug 2022 09:02:21 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN [v2] In-Reply-To: References: <1NFoDPRrsPLi3hsc8l0kl1HTIfebbfAjezP0-ASDtis=.cc2874b4-ffd4-4310-b61c-aec1233f45ae@github.com> Message-ID: On Thu, 25 Aug 2022 09:39:42 GMT, Pengfei Li wrote: >> Ok. Can you reword the comment to state that explicitly? > > Done in latest commit Since there is now only a single assignment, I suggest to move the assignment out of the condition to make it more readable and more clear that we cannot have `con == 0` afterwards. const jint con = in(2)->find_int_con(0); if (con == 0) { ... Same further down for `MulL`. ------------- PR: https://git.openjdk.org/jdk/pull/9820 From stefank at openjdk.org Fri Aug 26 09:10:13 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 09:10:13 GMT Subject: RFR: 8292921: Rewrite object field printer [v6] In-Reply-To: References: Message-ID: > See this as a RFC rather than a fully ready PR: > > fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. > > This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) > > and with the suggested change we get: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) > > which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). > > I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. > > There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. > > A full example of the generated output: > > java.lang.Class > {0x00007ffc36801080} - klass: 'java/lang/Class' > - ---- fields (total size 26 words): > - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) > - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) > - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) > - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) > - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) > - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) > - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) > - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) > - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) > - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) > - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) > - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) > - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) > - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) > - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) > - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) > - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) > - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) > - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) > - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) > - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) > - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) > - signature: Ljava/lang/String; > - ---- static fields (2): > - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) > - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) > - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) > - private static final 'REPL' 'C' @200 65533 (0x0000fffd) > - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) > - static final 'LATIN1' 'B' @203 0 (0x00000000) > - static final 'UTF16' 'B' @204 1 (0x00000001) Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Introduce and use various 0x0... prefixed integer format specifiers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10028/files - new: https://git.openjdk.org/jdk/pull/10028/files/e1f05e4a..96258aaf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10028&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10028&range=04-05 Stats: 34 lines in 2 files changed: 7 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/10028.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10028/head:pull/10028 PR: https://git.openjdk.org/jdk/pull/10028 From aboldtch at openjdk.org Fri Aug 26 09:28:07 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 26 Aug 2022 09:28:07 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v7] In-Reply-To: References: <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com> Message-ID: On Thu, 25 Aug 2022 22:20:43 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4157: >> >>> 4155: } >>> 4156: } >>> 4157: log_debug(redefine, class, nmethod)("Enqueued all nmethods for deopt"); >> >> This seems to do the opposite of encapsulating nmethod logic by exposing RedefineClasses to the interesting bits of CodeCache iteration. And details of deoptimization that redefine classes really has other things to worry about. I didn't realize you were doing this. I suppose it's better than a big #if JVMTI in codeCache.cpp. > > Maybe this is ok, but I want to look at it more. The reason these functions started out in codeCache is because they looked like other functions in codeCache. The encapsulation is about defining an API for deoptimization which can enforce invariants and be safer to use. ```C++ // A DeoptimizationContext provides an API for deoptimizing CompileMethods // The contract for using a DeoptimizationContext is as follows // The context is active from the DeoptimizationContext objects creating // until deoptimize() is called on the object. // While the context is active, // * no safepoint may be taken // * any interaction with the context object must be done under // the Compile_lock // * deoptimize() must be called // While the context is inactive // * only interaction with the DeoptimizationContext object may // calls to enqueued() and its destruction The idea with the API is that the logic of how compiled methods are selected is done in a context which wants to use the API, like class redefinition, class dependency changes, method handles, call site changes etc. The goal was to move all the deoptimization logic from the codeCache to deoptimization. The JTMTI code got moved to jvmtiRedefineClasses as it had separate JVMTI specific logic. Storing old methods, etc. But I think some of the code that got moved from codeCache to deoptimization should/could be moved to instanceKlass, method, dependencies etc. as well. The reason I only moved the JVMTI code is because it had side effects(separate from deoptimization). While all the other were only help functions which made dependency traversal easier. The only reason I feel reluctance about moving the JVMTI code to deoptimization is because it then must be old_compiled_method_table aware. But if you have some reason why it should be in deoptimization I would like to know. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From stuefe at openjdk.org Fri Aug 26 09:33:22 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 26 Aug 2022 09:33:22 GMT Subject: RFR: 8292921: Rewrite object field printer [v6] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 09:10:13 GMT, Stefan Karlsson wrote: >> See this as a RFC rather than a fully ready PR: >> >> fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. >> >> This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) >> >> and with the suggested change we get: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) >> >> which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). >> >> I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. >> >> There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. >> >> A full example of the generated output: >> >> java.lang.Class >> {0x00007ffc36801080} - klass: 'java/lang/Class' >> - ---- fields (total size 26 words): >> - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) >> - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) >> - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) >> - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) >> - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) >> - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) >> - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) >> - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) >> - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) >> - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) >> - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) >> - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) >> - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) >> - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) >> - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) >> - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) >> - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) >> - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) >> - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) >> - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) >> - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) >> - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) >> - signature: Ljava/lang/String; >> - ---- static fields (2): >> - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) >> - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) >> - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) >> - private static final 'REPL' 'C' @200 65533 (0x0000fffd) >> - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) >> - static final 'LATIN1' 'B' @203 0 (0x00000000) >> - static final 'UTF16' 'B' @204 1 (0x00000001) > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Introduce and use various 0x0... prefixed integer format specifiers Looks good. I like the new format macros. Somehow I was assuming xxx_FORMAT_X was already 0-padding. But this is better. src/hotspot/share/utilities/globalDefinitions.hpp line 95: > 93: #define BOOL_TO_STR(_b_) ((_b_) ? "true" : "false") > 94: > 95: // Format 8-bit quantities. Maybe a little comment explaining the various suffixes? ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/10028 From stefank at openjdk.org Fri Aug 26 09:36:08 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 09:36:08 GMT Subject: RFR: 8292921: Rewrite object field printer [v6] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 09:29:50 GMT, Thomas Stuefe wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Introduce and use various 0x0... prefixed integer format specifiers > > src/hotspot/share/utilities/globalDefinitions.hpp line 95: > >> 93: #define BOOL_TO_STR(_b_) ((_b_) ? "true" : "false") >> 94: >> 95: // Format 8-bit quantities. > > Maybe a little comment explaining the various suffixes? Sure ------------- PR: https://git.openjdk.org/jdk/pull/10028 From aboldtch at openjdk.org Fri Aug 26 09:42:05 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 26 Aug 2022 09:42:05 GMT Subject: Integrated: 8292868: Explicitly pass a third temp register to MacroAssembler::store_heap_oop for aarch64 In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 10:11:30 GMT, Axel Boldt-Christmas wrote: > Currently G1 (and Shenandoah) implicitly uses r3 on aarch64 in store_at. > > This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). This would be fixed in the same way on aarch64 by passing the temporary register explicitly so it is part of the GC api > > Testing: Oracle aarch64 platforms tier 1-3 This pull request has now been integrated. Changeset: f91943c1 Author: Axel Boldt-Christmas Committer: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/f91943c19fc0b060684a437d2c768461d54c088e Stats: 68 lines in 16 files changed: 2 ins; 0 del; 66 mod 8292868: Explicitly pass a third temp register to MacroAssembler::store_heap_oop for aarch64 Reviewed-by: shade, eosterlund, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/10019 From stefank at openjdk.org Fri Aug 26 09:56:02 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 09:56:02 GMT Subject: RFR: 8292921: Rewrite object field printer [v7] In-Reply-To: References: Message-ID: > See this as a RFC rather than a fully ready PR: > > fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. > > This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) > > and with the suggested change we get: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) > > which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). > > I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. > > There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. > > A full example of the generated output: > > java.lang.Class > {0x00007ffc36801080} - klass: 'java/lang/Class' > - ---- fields (total size 26 words): > - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) > - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) > - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) > - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) > - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) > - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) > - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) > - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) > - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) > - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) > - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) > - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) > - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) > - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) > - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) > - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) > - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) > - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) > - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) > - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) > - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) > - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) > - signature: Ljava/lang/String; > - ---- static fields (2): > - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) > - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) > - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) > - private static final 'REPL' 'C' @200 65533 (0x0000fffd) > - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) > - static final 'LATIN1' 'B' @203 0 (0x00000000) > - static final 'UTF16' 'B' @204 1 (0x00000001) Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Guide to integer format specifier suffixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10028/files - new: https://git.openjdk.org/jdk/pull/10028/files/96258aaf..bcf50594 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10028&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10028&range=05-06 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10028.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10028/head:pull/10028 PR: https://git.openjdk.org/jdk/pull/10028 From duke at openjdk.org Fri Aug 26 09:57:01 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 26 Aug 2022 09:57:01 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v4] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 16:23:41 GMT, Kim Barrett wrote: >> Johan Sj?l?n has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Fix tests for updated threadHelper >> - Remove outdated threadHelper >> - Update documentation >> - Fix outdated headers and remove dead code >> - Review comments >> - Implement MRSWMutex > > src/hotspot/share/utilities/readWriteLock.hpp line 82: > >> 80: // >> 81: volatile int32_t _count; >> 82: > > This class should be noncopyable. Maybe it is implicitly so via the `PlatformMonitor` member, but would be better to be explicit. It is! See L54. > src/hotspot/share/utilities/readWriteLock.hpp line 89: > >> 87: } >> 88: >> 89: ~ReadWriteLock() { > > Use default destructor (either implicit or explicit) rather than empty body destructor. Good point, made it explicit. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From stefank at openjdk.org Fri Aug 26 09:57:18 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 09:57:18 GMT Subject: RFR: 8292921: Rewrite object field printer [v6] In-Reply-To: References: Message-ID: <64asoQ0D0dgmO8aArcUW97NI5nCNWHbwIN5qanH_PjU=.9c7d1b14-da4d-4811-a72d-9ee168589bab@github.com> On Fri, 26 Aug 2022 09:33:28 GMT, Stefan Karlsson wrote: >> src/hotspot/share/utilities/globalDefinitions.hpp line 95: >> >>> 93: #define BOOL_TO_STR(_b_) ((_b_) ? "true" : "false") >>> 94: >>> 95: // Format 8-bit quantities. >> >> Maybe a little comment explaining the various suffixes? > > Sure Added a comment. I see that there's some inconsistency, with the names used for SIZE_FORMAT_HEX. And we could probably replace PTR32_FORMAT/PTR64_FORMAT/INTPTRNZ_FORMAT, now that we have these new integer format specifiers. I'd like to do that cleanup as a separate patch. ------------- PR: https://git.openjdk.org/jdk/pull/10028 From duke at openjdk.org Fri Aug 26 10:03:58 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 26 Aug 2022 10:03:58 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v4] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 16:28:59 GMT, Kim Barrett wrote: >> Johan Sj?l?n has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Fix tests for updated threadHelper >> - Remove outdated threadHelper >> - Update documentation >> - Fix outdated headers and remove dead code >> - Review comments >> - Implement MRSWMutex > > src/hotspot/share/utilities/readWriteLock.cpp line 42: > >> 40: _mon.wait(0); >> 41: } >> 42: }; > > Why is this a lambda rather than a (private) ordinary member function? There's a bunch of these. Use of lambda reduces the separation of the code from it's use, but that doesn't seem to me worth the additional clutter. I'd rather a well-named helper function here, esp. since in this case would be the same helper as used by write_lock. Call it await_write_unlock. Consider putting the thread-type handling in the helper too, keeping this function small. Good point, as it's used twice and has a clear name and purpose it works well as a private member function. I also changed the other lambda into a member function, for symmetry. > Consider putting the thread-type handling in the helper too, keeping this function small. To me, it's less surprising to find such handling in the main method. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From stefank at openjdk.org Fri Aug 26 10:12:55 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 10:12:55 GMT Subject: RFR: 8292921: Rewrite object field printer [v6] In-Reply-To: <64asoQ0D0dgmO8aArcUW97NI5nCNWHbwIN5qanH_PjU=.9c7d1b14-da4d-4811-a72d-9ee168589bab@github.com> References: <64asoQ0D0dgmO8aArcUW97NI5nCNWHbwIN5qanH_PjU=.9c7d1b14-da4d-4811-a72d-9ee168589bab@github.com> Message-ID: On Fri, 26 Aug 2022 09:55:07 GMT, Stefan Karlsson wrote: >> Sure > > Added a comment. I see that there's some inconsistency, with the names used for SIZE_FORMAT_HEX. And we could probably replace PTR32_FORMAT/PTR64_FORMAT/INTPTRNZ_FORMAT, now that we have these new integer format specifiers. I'd like to do that cleanup as a separate patch. Hmm. I found some more inconsistencies. I think at this point, It would be better if I just unified all the format specifier macros, and rename this bug. ------------- PR: https://git.openjdk.org/jdk/pull/10028 From duke at openjdk.org Fri Aug 26 11:50:01 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 26 Aug 2022 11:50:01 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v4] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 19:25:55 GMT, Kim Barrett wrote: >> Johan Sj?l?n 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: >> >> - Fix tests for updated threadHelper >> - Remove outdated threadHelper >> - Update documentation >> - Fix outdated headers and remove dead code >> - Review comments >> - Implement MRSWMutex > > src/hotspot/share/utilities/readWriteLock.cpp line 32: > >> 30: #include "utilities/readWriteLock.hpp" >> 31: >> 32: void ReadWriteLock::read_lock(Thread *current) { > > The more common (though far from universal) style in HotSpot code cuddles the `*` punctuator with the type rather than the variable, i.e. `Thread* current`. Good find, we have two different styles in the header and this file too. > src/hotspot/share/utilities/readWriteLock.cpp line 64: > >> 62: void ReadWriteLock::read_unlock() { >> 63: for (;;) { >> 64: const int32_t count = Atomic::load_acquire(&_count); > > I think an invariant here is that count is never 0 or -1. Consider asserting that. Good find. > src/hotspot/share/utilities/readWriteLock.cpp line 81: > >> 79: if (count == -2) { >> 80: Locker locker(&_mon); >> 81: _mon.notify_all(); > > Unfortunately, this also wakes up all pending readers. I wonder if there's a way to avoid that by having two monitors (only having monitors and not bare condvars makes that harder). Yes. I propose leaving this work for a future RFE. There are many potential improvements, I want to await the need for those to implement them. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From jbhateja at openjdk.org Fri Aug 26 13:42:16 2022 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 26 Aug 2022 13:42:16 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v3] In-Reply-To: References: Message-ID: > Hi, > > This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. > A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8291649: Incorporating code changes from Kim and John. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9987/files - new: https://git.openjdk.org/jdk/pull/9987/files/369bbd7a..629c584e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9987&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9987&range=01-02 Stats: 232 lines in 3 files changed: 112 ins; 72 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/9987.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9987/head:pull/9987 PR: https://git.openjdk.org/jdk/pull/9987 From stefank at openjdk.org Fri Aug 26 13:43:37 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 13:43:37 GMT Subject: RFR: 8292921: Rewrite object field printer [v7] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 09:56:02 GMT, Stefan Karlsson wrote: >> See this as a RFC rather than a fully ready PR: >> >> fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. >> >> This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) >> >> and with the suggested change we get: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) >> >> which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). >> >> I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. >> >> There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. >> >> A full example of the generated output: >> >> java.lang.Class >> {0x00007ffc36801080} - klass: 'java/lang/Class' >> - ---- fields (total size 26 words): >> - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) >> - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) >> - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) >> - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) >> - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) >> - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) >> - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) >> - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) >> - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) >> - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) >> - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) >> - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) >> - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) >> - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) >> - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) >> - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) >> - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) >> - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) >> - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) >> - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) >> - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) >> - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) >> - signature: Ljava/lang/String; >> - ---- static fields (2): >> - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) >> - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) >> - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) >> - private static final 'REPL' 'C' @200 65533 (0x0000fffd) >> - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) >> - static final 'LATIN1' 'B' @203 0 (0x00000000) >> - static final 'UTF16' 'B' @204 1 (0x00000001) > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Guide to integer format specifier suffixes I've created a new PR (#10042) for the integer format specifier changes. This PR is put into the draft state until #10042 has been resolved. ------------- PR: https://git.openjdk.org/jdk/pull/10028 From stefank at openjdk.org Fri Aug 26 13:45:26 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 13:45:26 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers Message-ID: Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. I'd like to suggest that we use a convention to specify what we want. This is the current proposal: // Guide to the suffixes used in the format specifiers for integers: // - print the decimal value: 745565 // _X - print as hexadecimal, without leading 0s: 0x12345 // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 // _H - print as hexadecimal, without 0x prefix // _W(w) - prints w sized string with the given value right // adjusted. Use -w to print left adjusted. // // Note that the PTR format specifiers print using 0x with leading zeros, // just like the _X_0 version for integers. The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. ------------- Commit messages: - 8292981: Unify and restructure integer printing format specifiers Changes: https://git.openjdk.org/jdk/pull/10042/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292981 Stats: 145 lines in 26 files changed: 35 ins; 21 del; 89 mod Patch: https://git.openjdk.org/jdk/pull/10042.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10042/head:pull/10042 PR: https://git.openjdk.org/jdk/pull/10042 From stefank at openjdk.org Fri Aug 26 13:46:11 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 13:46:11 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory [v2] In-Reply-To: <54k4QZxdzCTj29jsLcnWtlZ5HtXxN4Zl7X4aqUmgObQ=.1ddad8cd-3ead-4356-8346-821fa0ca7aa1@github.com> References: <54k4QZxdzCTj29jsLcnWtlZ5HtXxN4Zl7X4aqUmgObQ=.1ddad8cd-3ead-4356-8346-821fa0ca7aa1@github.com> Message-ID: On Thu, 25 Aug 2022 06:09:30 GMT, Stefan Karlsson wrote: >> HotSpot performs "critical metaspace allocations" when it's running out of metaspace. The failed allocations are registered in a queue, which the GC prioritizes when cleaning up the metaspace. There's a race in the code that handles these requests. >> >> These requests are added to the queue, and the GC will "process" each request in turn when it runs the metaspace purge phase. The queue handling has an optimization that says that only the first request in the queue needs to trigger the GC, all subsequent requests in the queue will wait for that GC. When the GC gets to the purge phase it will mark in all requests that they have been processed. Note: that this doesn't mean that the request was satisfied, it could be that the result was NULL (and the thread will trigger a last-effort GC before it throws an OOME). >> >> The bug is in the code that determines if a request is responsible for triggering a new GC. The current code just checks if the current request is first in the queue. This doesn't work if the code is called just after the GC has run purge, but before the old requests have been removed. The new request sees that there are already elements in the queue, so it doesn't trigger the GC. And at the same time, the old requests have been processed and they won't trigger the GC either. So, now the new request is waiting for a GC that will not be triggered by anyone. >> >> Note: The reason why there's a delay between the GC processing a request, and the removal from the queue, is that the Java thread that added the request is also responsible for removing the request form the queue. The reason for this is that the mentioned last-effort GC, needs to be able to process the request a second time. >> >> The fix-proposal is to let threads adding new requests check if the added request is the first *non-processed* request in the queue. If it is, that request/thread is responsible for triggering the GC for itself, and any subsequently added requests (until the GC runs the next round of request processing). >> >> However, there's a snatch to this proposal. The request processing is done inside `Metaspace::purge()`, and that function is skipped if the GC didn't unload any classes. The proposed logic relies on that function to always be run when a GC is running. So, I've also changed so that the GC unconditionally calls the request processing. An alternative would be to always run the Metaspace::purge() code. That might even help return memory from temporarily allocated metaspace memory earlier, but I've left that exercise for a potential future improvement. >> >> I've also tweaked the test so that we get a bit more info if this test fails again. >> >> Testing: I could reliably reproduce the original hang on my macbook laptop, within a few minutes. With this fix I can run the test in a loop for hours without reproducing the hang. I've tested this together with Generational ZGC code, running tier1-tier7 on Linux x64. I've started more extensive testing on openjdk/jdk. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Update test text Thanks for the reviews! ------------- PR: https://git.openjdk.org/jdk/pull/9985 From stefank at openjdk.org Fri Aug 26 13:47:29 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 13:47:29 GMT Subject: Integrated: 8292697: ZGC: Hangs when almost out of metaspace memory In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 15:56:54 GMT, Stefan Karlsson wrote: > HotSpot performs "critical metaspace allocations" when it's running out of metaspace. The failed allocations are registered in a queue, which the GC prioritizes when cleaning up the metaspace. There's a race in the code that handles these requests. > > These requests are added to the queue, and the GC will "process" each request in turn when it runs the metaspace purge phase. The queue handling has an optimization that says that only the first request in the queue needs to trigger the GC, all subsequent requests in the queue will wait for that GC. When the GC gets to the purge phase it will mark in all requests that they have been processed. Note: that this doesn't mean that the request was satisfied, it could be that the result was NULL (and the thread will trigger a last-effort GC before it throws an OOME). > > The bug is in the code that determines if a request is responsible for triggering a new GC. The current code just checks if the current request is first in the queue. This doesn't work if the code is called just after the GC has run purge, but before the old requests have been removed. The new request sees that there are already elements in the queue, so it doesn't trigger the GC. And at the same time, the old requests have been processed and they won't trigger the GC either. So, now the new request is waiting for a GC that will not be triggered by anyone. > > Note: The reason why there's a delay between the GC processing a request, and the removal from the queue, is that the Java thread that added the request is also responsible for removing the request form the queue. The reason for this is that the mentioned last-effort GC, needs to be able to process the request a second time. > > The fix-proposal is to let threads adding new requests check if the added request is the first *non-processed* request in the queue. If it is, that request/thread is responsible for triggering the GC for itself, and any subsequently added requests (until the GC runs the next round of request processing). > > However, there's a snatch to this proposal. The request processing is done inside `Metaspace::purge()`, and that function is skipped if the GC didn't unload any classes. The proposed logic relies on that function to always be run when a GC is running. So, I've also changed so that the GC unconditionally calls the request processing. An alternative would be to always run the Metaspace::purge() code. That might even help return memory from temporarily allocated metaspace memory earlier, but I've left that exercise for a potential future improvement. > > I've also tweaked the test so that we get a bit more info if this test fails again. > > Testing: I could reliably reproduce the original hang on my macbook laptop, within a few minutes. With this fix I can run the test in a loop for hours without reproducing the hang. I've tested this together with Generational ZGC code, running tier1-tier7 on Linux x64. I've started more extensive testing on openjdk/jdk. This pull request has now been integrated. Changeset: 3844685b Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/3844685be03b121e75095b45a76c0b99f2a41912 Stats: 84 lines in 7 files changed: 51 ins; 5 del; 28 mod 8292697: ZGC: Hangs when almost out of metaspace memory Reviewed-by: eosterlund, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/9985 From coleenp at openjdk.org Fri Aug 26 13:52:31 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 26 Aug 2022 13:52:31 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable Message-ID: Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. Also tested with tier1-7. ------------- Commit messages: - Beef up the Test for statistics - 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable Changes: https://git.openjdk.org/jdk/pull/10043/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292375 Stats: 285 lines in 9 files changed: 84 ins; 148 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Fri Aug 26 14:14:55 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 26 Aug 2022 14:14:55 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Cleanup things I just noticed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10043/files - new: https://git.openjdk.org/jdk/pull/10043/files/20eeab38..1a817535 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From stefank at openjdk.org Fri Aug 26 14:21:51 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 26 Aug 2022 14:21:51 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v2] In-Reply-To: References: Message-ID: > Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. > > This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. > > We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. > > I'd like to suggest that we use a convention to specify what we want. This is the current proposal: > > // Guide to the suffixes used in the format specifiers for integers: > // - print the decimal value: 745565 > // _X - print as hexadecimal, without leading 0s: 0x12345 > // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 > // _H - print as hexadecimal, without 0x prefix > // _W(w) - prints w sized string with the given value right > // adjusted. Use -w to print left adjusted. > // > // Note that the PTR format specifiers print using 0x with leading zeros, > // just like the _X_0 version for integers. > > > The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Fix Shenandoah ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10042/files - new: https://git.openjdk.org/jdk/pull/10042/files/f64eecaf..b19c7d0e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10042.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10042/head:pull/10042 PR: https://git.openjdk.org/jdk/pull/10042 From mdoerr at openjdk.org Fri Aug 26 15:36:17 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 26 Aug 2022 15:36:17 GMT Subject: RFR: 8290025: Remove the Sweeper [v13] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 09:10:20 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Missing PPC code Some more information about the "Out of space in CodeCache for adapters" issue: The test was running with less than 240MB ReservedCodeCacheSize. The VM doesn't enable SegmentedCodeCache in this case. Seems like the new implementation doesn't make sure we have enough space for adapters without SegmentedCodeCache, but we're not using this case in production. May still be a a good enhancement. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From ccheung at openjdk.org Fri Aug 26 16:32:57 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 26 Aug 2022 16:32:57 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v4] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 04:49:15 GMT, Ioi Lam wrote: >> Some CDS functions are always compiled, even when CDS is not enabled (e.g., for the minimal VM). >> >> This RFE puts some of the obvious ones inside `#if INCLUDE_CDS` blocks. >> >> Note: my goal is not to make the minimal VM as small as possible. But rather, I don't want to put `#if INCLUDE_CDS` inside each of those functions that access a CDS-only feature. (E.g., `ConstantPoolCache::save_for_archive`, which accesses `_initial_entries`, which is declared only when CDS is enabled). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10010 From stuefe at openjdk.org Fri Aug 26 16:54:03 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 26 Aug 2022 16:54:03 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory [v2] In-Reply-To: <54k4QZxdzCTj29jsLcnWtlZ5HtXxN4Zl7X4aqUmgObQ=.1ddad8cd-3ead-4356-8346-821fa0ca7aa1@github.com> References: <54k4QZxdzCTj29jsLcnWtlZ5HtXxN4Zl7X4aqUmgObQ=.1ddad8cd-3ead-4356-8346-821fa0ca7aa1@github.com> Message-ID: <1xAJmoZVDBsIB4S6DK7bS26QwuCqEHNQWaD_L_4Muj0=.8c586a41-17d0-4bc5-943c-26172b8573fb@github.com> On Thu, 25 Aug 2022 06:09:30 GMT, Stefan Karlsson wrote: >> HotSpot performs "critical metaspace allocations" when it's running out of metaspace. The failed allocations are registered in a queue, which the GC prioritizes when cleaning up the metaspace. There's a race in the code that handles these requests. >> >> These requests are added to the queue, and the GC will "process" each request in turn when it runs the metaspace purge phase. The queue handling has an optimization that says that only the first request in the queue needs to trigger the GC, all subsequent requests in the queue will wait for that GC. When the GC gets to the purge phase it will mark in all requests that they have been processed. Note: that this doesn't mean that the request was satisfied, it could be that the result was NULL (and the thread will trigger a last-effort GC before it throws an OOME). >> >> The bug is in the code that determines if a request is responsible for triggering a new GC. The current code just checks if the current request is first in the queue. This doesn't work if the code is called just after the GC has run purge, but before the old requests have been removed. The new request sees that there are already elements in the queue, so it doesn't trigger the GC. And at the same time, the old requests have been processed and they won't trigger the GC either. So, now the new request is waiting for a GC that will not be triggered by anyone. >> >> Note: The reason why there's a delay between the GC processing a request, and the removal from the queue, is that the Java thread that added the request is also responsible for removing the request form the queue. The reason for this is that the mentioned last-effort GC, needs to be able to process the request a second time. >> >> The fix-proposal is to let threads adding new requests check if the added request is the first *non-processed* request in the queue. If it is, that request/thread is responsible for triggering the GC for itself, and any subsequently added requests (until the GC runs the next round of request processing). >> >> However, there's a snatch to this proposal. The request processing is done inside `Metaspace::purge()`, and that function is skipped if the GC didn't unload any classes. The proposed logic relies on that function to always be run when a GC is running. So, I've also changed so that the GC unconditionally calls the request processing. An alternative would be to always run the Metaspace::purge() code. That might even help return memory from temporarily allocated metaspace memory earlier, but I've left that exercise for a potential future improvement. >> >> I've also tweaked the test so that we get a bit more info if this test fails again. >> >> Testing: I could reliably reproduce the original hang on my macbook laptop, within a few minutes. With this fix I can run the test in a loop for hours without reproducing the hang. I've tested this together with Generational ZGC code, running tier1-tier7 on Linux x64. I've started more extensive testing on openjdk/jdk. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Update test text src/hotspot/share/memory/metaspace.cpp line 998: > 996: } > 997: > 998: void Metaspace::purge(bool classes_unloaded) { Would it not have been more logical to heave both `MetaspaceCritical_lock` and `MetaspaceCriticalAllocation::process();` out of this function? As it is, `Metaspace::purge`, called with false, is now a no-op that only does things on behalf of the GC. It has nothing to do with the functioning of the allocator. ------------- PR: https://git.openjdk.org/jdk/pull/9985 From john.r.rose at oracle.com Fri Aug 26 17:00:46 2022 From: john.r.rose at oracle.com (John Rose) Date: Fri, 26 Aug 2022 10:00:46 -0700 Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v2] In-Reply-To: <8ED40C4E-FB11-4B7E-89A2-AF8E0ED78816@oracle.com> References: <55UCDLv71g3p2WruG3x2ihLvFAjtA1HTGHLod1uI-RY=.0295efe2-af4b-47d9-a68e-d2be1bb21af0@github.com> <8ED40C4E-FB11-4B7E-89A2-AF8E0ED78816@oracle.com> Message-ID: <1674BB6C-D880-4D7B-ABE3-CC334768F5DB@oracle.com> After sleeping on it I realize I like Kim?s improvements better than my code which does not derive the type `I`. The use of metaprogramming (or whatever it is) to derive the ad hoc type `I` using funny conditionals does in fact make for logic that more clearly expresses how the integral promotion rules of C++ will affect the outcome. Suggestion: To the gtest unit test, add the following block to advise folks how to check code quality: ``` // To manually check code quality, try these commands: // // $ make hotspot exploded-test TEST=gtest:moveBits // $ objdump -D $(find build -name test_moveBits.o) > /tmp/foo // $ sed < /tmp/foo -n /quality/,/stream/p | grep -B20 bswap // // Or adapt $(find build -name test_moveBits.o.cmdline) // replacing -c by -S and -o test_moveBits.s. ``` On 26 Aug 2022, at 1:07, John Rose wrote: > Thanks; right. I like your improvements, except the metaprogramming. > > Here?s what I got: > > https://github.com/openjdk/jdk/compare/master...rose00:jdk:moveBits > > I?m not against metaprogramming when we need it, but there are > alternatives here to deriving the extra types; the tricks are > explained in the comments. I suppose it?s a matter of taste whether > the metaprogramming is more or less obscure than the bit-twiddling > tricks, but I will observe that bit-twiddling tricks are the focus of > this file. > > I verified by hand that you get good code in all cases, even without > explicit mentions of the intrinsics. Here?s an easy way to start > that process: > > ``` > $ make hotspot exploded-test TEST=gtest:moveBits > $ objdump -D $(find build -name test_moveBits.o) > /tmp/foo > $ sed < /tmp/foo -n /quality/,/stream/p | grep -B20 bswap > > ``` > > > On 25 Aug 2022, at 23:39, Kim Barrett wrote: > >> On Fri, 26 Aug 2022 01:06:25 GMT, John R Rose >> wrote: >> >>>> src/hotspot/share/utilities/moveBits.hpp line 31: >>>> >>>>> 29: #include "utilities/globalDefinitions.hpp" >>>>> 30: >>>>> 31: inline uint32_t reverse_bits_in_bytes_int(uint32_t x) { >>>> >>>> Instead of two functions with different names (suffixed `_int` and >>>> `_long`), have one function name that has two overloads >>>> disambiguated by the size of the argument, e.g. >>>> >>>> >>>> template >>>> constexpr T reverse_bits_in_bytes(T x) { ... } >>>> >>>> template >>>> constexpr T reverse_bits_in_bytes(T x) { ... } >>>> >>>> >>>> This allows `reverse_bits` to look something like >>>> >>>> >>>> template::value)> >>>> constexpr T reverse_bits(T v) { >>>> return reverse_bytes(reverse_bits_in_bytes(v)); >>>> } >>> >>> Yes, that could work. >>> >>> This also works, and feels appropriately short + sweet to me: >>> >>> https://github.com/rose00/jdk/pull/new/moveBits >>> >>> (I also added a 90+% level gtest.) >>> >>> (Sorry; amended with `constexpr` and force-pushed?) >> >> I took John's code and made various (I think) improvements: >> https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:reverse-bits?expand=1 >> >>>> src/hotspot/share/utilities/moveBits.hpp line 63: >>>> >>>>> 61: >>>>> /***************************************************************************** >>>>> 62: * GCC and compatible (including Clang) >>>>> 63: >>>>> *****************************************************************************/ >>>> >>>> Is it really worth the extra code to allow the use of the gcc >>>> builtins? >>> >>> Kim, is there a way to do this in less code? >>> >>> Seems to me that something like this could work: >>> >>> >>> template >>> T reverse_bytes(T x) { >>> if (size == 1) return x; >>> T alt8bs = (T)((uint64_t)-1 / 0xFFFF * 0xFF); // 0x00FF?00FF >>> x = ((x & alt8bs) << 8) | (((uint64_t)x >> 8 & alt8bs); >>> if (size == 2) return x; >>> T alt16bs = (T)((uint64_t)-1 / 0xFFFFFFFFll * 0xFFFF); // >>> 0x0000FFFF?0000FFFF >>> ? >>> } >>> >>> >>> That is, one function bodies handles cases for 1/2/4/8 byte values. >>> >>> Could it be just a function template, with an explicit instantiation >>> (overriding the general template) where it matches an intrinsic? >> >> Answering my own question, no, it's not worth the extra code. gcc >> (and likely other compilers) are quite good at recognizing byte >> swapping code and transforming it into the appropriate >> platform-specific code like x86 bswap. >> >> ------------- >> >> PR: https://git.openjdk.org/jdk/pull/9987 -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleenp at openjdk.org Fri Aug 26 17:07:54 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 26 Aug 2022 17:07:54 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: Message-ID: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: include mutexLocker.hpp for minimal build. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10043/files - new: https://git.openjdk.org/jdk/pull/10043/files/1a817535..842b30ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From duke at openjdk.org Fri Aug 26 17:58:54 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Fri, 26 Aug 2022 17:58:54 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: References: Message-ID: <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com> On Tue, 23 Aug 2022 15:05:48 GMT, Ashutosh Mehra wrote: > Please review this patch to fix the crash when running Loom with Shenandoah in iu+aggressive mode. > > When running with `-XX:+ShenandoahVerify`, the issue manifests as assertion at: > > > 1 # > 2 # A fatal error has been detected by the Java Runtime Environment: > 3 # > 4 # Internal Error (/home/asmehra/data/ashu-mehra/loom/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:92), pid=920144, tid=920156 > 5 # Error: Before Evacuation, Reachable; Must be marked in complete bitmap, except j.l.r.Reference referents > 6 > 7 Referenced from: > 8 interior location: 0x00007f0a40000090 > 9 0x00007f0a40000060 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk > 10 allocated after mark start > 11 not after update watermark > 12 marked strong > 13 marked weak > 14 not in collection set > 15 mark: mark(is_neutral no_hash age=0) > 16 region: | 0|R |BTE 7f0a40000000, 7f0a401ff9b0, 7f0a40200000|TAMS 7f0a40000000|UWM 7f0a401ff9b0|U 2046K|T 2046K|G 0B|S 0B|L 2046K|CP 0 > 17 > 18 Object: > 19 0x00007f0c2f848a40 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk > 20 not allocated after mark start > 21 not after update watermark > 22 not marked strong > 23 not marked weak > 24 in collection set > 25 mark: mark(is_neutral no_hash age=0) > 26 region: | 3964|CS |BTE 7f0c2f800000, 7f0c2fa00000, 7f0c2fa00000|TAMS 7f0c2fa00000|UWM 7f0c2fa00000|U 2048K|T 0B|G 2048K|S 0B|L 1612K|CP 0 > 27 > 28 Forwardee: > 29 (the object itself) > > > The StackChunk object `0x00007f0c2f848a40` is not marked which happens to be referenced from the parent field of the newly allocated StackChunk object `0x00007f0a40000060`. > The sequence for setting `StackChunk::parent` is as follows. At some point during the process of freezing the continuation, the jvm does: > > > continuationWrapper::_tail = stackChunk1 > stackChunk2 = allocate new StackChunk > stackChunk2::parent = continuationWrapper::_tail > continuationWrapper::_tail = stackChunk2 > > > At the end of the sequence stackChunk1 is only reachable from stackChunk2. If stackChunk2 happens to be allocated after concurrent mark has started and if the shenandoahgc is using IU mode, then the stackChunk2 would would not be scanned. This results in gc missing the marking of stackChunk1 which triggers the the assertion during heap verification. > > This is similar to the sequence described by @fisk [here](https://github.com/openjdk/jdk19/pull/140#issuecomment-1185491224) > > There is code in `FreezeBase::finish_freeze()` to call `stackChunkOopDesc::do_barriers()` which triggers the gc barriers for the newly allocated StackChunk object. But it has two problems: > 1. The call to `stackChunkOopDesc::do_barriers()` is guarded by a flag [1] which is false for StackChunk objects allocated after marking has started [2] > 2. `stackChunkOopDesc::do_barriers()` currently triggers the gc barriers for the oops in the stack represented by the newly allocated StackChunk, but it ignores the oops in the StackChunk header > > To fix these two issues, we need the following changes: > 1. Always enable barrier for Shenandoah IU mode (this change is same as 8288129: Shenandoah: Skynet test crashed with iu + aggressive #9494). > 2. Add the code in `stackChunkOopDesc::do_barriers` to run the barriers on the oops present in the stack chunk header. > > [1] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1201 > [2] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L2308 > > Signed-off-by: Ashutosh Mehra @stefank @fisk I see this code [1] which indicates ZGC does not require barriers at all. I would appreciate if either of you can provide inputs on how does ZGC handles the scenario where the previously reachable object O1 is now reachable only from another object O2 allocated after marking has started. How would O1 be marked by ZGC in such case? This seems to be the scenario we are hitting in the context of loom code during the freeze process and shenandoah IU mode fails to handle it. [1] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1299 ------------- PR: https://git.openjdk.org/jdk/pull/9982 From jrose at openjdk.org Fri Aug 26 19:14:00 2022 From: jrose at openjdk.org (John R Rose) Date: Fri, 26 Aug 2022 19:14:00 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v3] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 13:42:16 GMT, Jatin Bhateja wrote: >> Hi, >> >> This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. >> A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8291649: Incorporating code changes from Kim and John. test/hotspot/gtest/opto/test_moveBits.cpp line 77: > 75: } > 76: > 77: // here is some object code to look at: Here's a more useful comment: // Here is some object code to look at if we want to do a manual // study. One could find the build file named test_moveBits.o.cmdline // and hand-edit the command line to produce assembly code in // test_moveBits.s. // // Or, given the two empty "fence functions", one could do a // quick scan like this: // // $ objdump -D $(find build/*release -name test_moveBits.o) \ // | sed -n /start_code_quality/,/end_code_quality/p \ // | egrep -B10 bswap # or grep -B20 cfi_endproc void start_code_quality_moveBits() { } int16_t code_quality_reverse_bytes_16(int16_t x) { ? int64_t code_quality_reverse_bits_64(int64_t x) { return reverse_bits(x); // should compile to andq/shrq with 64-bit masks } void end_code_quality_moveBits() { } ------------- PR: https://git.openjdk.org/jdk/pull/9987 From jrose at openjdk.org Fri Aug 26 19:18:02 2022 From: jrose at openjdk.org (John R Rose) Date: Fri, 26 Aug 2022 19:18:02 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v3] In-Reply-To: References: Message-ID: <9cBr9RB39XtVMz2DSwCP827iOX4l9GqoNjPUmiN1NeQ=.1c22e637-b109-49ab-9dc7-28bd8c6386e6@github.com> On Fri, 26 Aug 2022 13:42:16 GMT, Jatin Bhateja wrote: >> Hi, >> >> This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. >> A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8291649: Incorporating code changes from Kim and John. I recommend using Kim's version; I decided I like his metaprogramming trick that creates the type `I` to precisely capture the details of C++ "usual integral promotions". The type of the `rep_XXX` constants should be `I` not `T` or `uint64_t`. See comment above about a helpful comment in the gtest file, so folks can readily make sure that the `bswap` instructions are used by the C++ compiler. ------------- Marked as reviewed by jrose (Reviewer). PR: https://git.openjdk.org/jdk/pull/9987 From sspitsyn at openjdk.org Fri Aug 26 20:19:53 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 26 Aug 2022 20:19:53 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals Message-ID: If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. ------------- Commit messages: - 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals Changes: https://git.openjdk.org/jdk/pull/10051/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10051&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292657 Stats: 41 lines in 6 files changed: 26 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10051.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10051/head:pull/10051 PR: https://git.openjdk.org/jdk/pull/10051 From duke at openjdk.org Fri Aug 26 20:22:57 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Fri, 26 Aug 2022 20:22:57 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive [v2] In-Reply-To: References: Message-ID: <9ah9SD1YhJdPEqRlH4n9k1NqWha3eTTuNaiQhywVP_Q=.9ab53e2a-4c10-4e2b-be4e-cf1483c2f12d@github.com> > Please review this patch to fix the crash when running Loom with Shenandoah in iu+aggressive mode. > > When running with `-XX:+ShenandoahVerify`, the issue manifests as assertion at: > > > 1 # > 2 # A fatal error has been detected by the Java Runtime Environment: > 3 # > 4 # Internal Error (/home/asmehra/data/ashu-mehra/loom/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:92), pid=920144, tid=920156 > 5 # Error: Before Evacuation, Reachable; Must be marked in complete bitmap, except j.l.r.Reference referents > 6 > 7 Referenced from: > 8 interior location: 0x00007f0a40000090 > 9 0x00007f0a40000060 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk > 10 allocated after mark start > 11 not after update watermark > 12 marked strong > 13 marked weak > 14 not in collection set > 15 mark: mark(is_neutral no_hash age=0) > 16 region: | 0|R |BTE 7f0a40000000, 7f0a401ff9b0, 7f0a40200000|TAMS 7f0a40000000|UWM 7f0a401ff9b0|U 2046K|T 2046K|G 0B|S 0B|L 2046K|CP 0 > 17 > 18 Object: > 19 0x00007f0c2f848a40 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk > 20 not allocated after mark start > 21 not after update watermark > 22 not marked strong > 23 not marked weak > 24 in collection set > 25 mark: mark(is_neutral no_hash age=0) > 26 region: | 3964|CS |BTE 7f0c2f800000, 7f0c2fa00000, 7f0c2fa00000|TAMS 7f0c2fa00000|UWM 7f0c2fa00000|U 2048K|T 0B|G 2048K|S 0B|L 1612K|CP 0 > 27 > 28 Forwardee: > 29 (the object itself) > > > The StackChunk object `0x00007f0c2f848a40` is not marked which happens to be referenced from the parent field of the newly allocated StackChunk object `0x00007f0a40000060`. > The sequence for setting `StackChunk::parent` is as follows. At some point during the process of freezing the continuation, the jvm does: > > > continuationWrapper::_tail = stackChunk1 > stackChunk2 = allocate new StackChunk > stackChunk2::parent = continuationWrapper::_tail > continuationWrapper::_tail = stackChunk2 > > > At the end of the sequence stackChunk1 is only reachable from stackChunk2. If stackChunk2 happens to be allocated after concurrent mark has started and if the shenandoahgc is using IU mode, then the stackChunk2 would would not be scanned. This results in gc missing the marking of stackChunk1 which triggers the the assertion during heap verification. > > This is similar to the sequence described by @fisk [here](https://github.com/openjdk/jdk19/pull/140#issuecomment-1185491224) > > There is code in `FreezeBase::finish_freeze()` to call `stackChunkOopDesc::do_barriers()` which triggers the gc barriers for the newly allocated StackChunk object. But it has two problems: > 1. The call to `stackChunkOopDesc::do_barriers()` is guarded by a flag [1] which is false for StackChunk objects allocated after marking has started [2] > 2. `stackChunkOopDesc::do_barriers()` currently triggers the gc barriers for the oops in the stack represented by the newly allocated StackChunk, but it ignores the oops in the StackChunk header > > To fix these two issues, we need the following changes: > 1. Always enable barrier for Shenandoah IU mode (this change is same as 8288129: Shenandoah: Skynet test crashed with iu + aggressive #9494). > 2. Add the code in `stackChunkOopDesc::do_barriers` to run the barriers on the oops present in the stack chunk header. > > [1] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1201 > [2] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L2308 > > Signed-off-by: Ashutosh Mehra Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Enable loom for ShenandoahGC IU mode Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9982/files - new: https://git.openjdk.org/jdk/pull/9982/files/5ce2ca34..d3894f8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9982&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9982&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9982/head:pull/9982 PR: https://git.openjdk.org/jdk/pull/9982 From kvn at openjdk.org Fri Aug 26 20:23:55 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 26 Aug 2022 20:23:55 GMT Subject: RFR: 8292694: x86_64 c2i/i2c adapters may use more stack space than necessary In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 03:08:20 GMT, Dean Long wrote: > The c2i adapter includes the return address in the alignment calculation, making %rsp always mis-aligned according to the ABI. > > The i2c adapter aligns "extrawords" even though %rsp is aligned later, and the incoming stack is not guaranteed to be aligned. Looks good to me. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10034 From coleenp at openjdk.org Fri Aug 26 20:25:59 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 26 Aug 2022 20:25:59 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v7] In-Reply-To: References: <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com> Message-ID: On Fri, 26 Aug 2022 09:25:52 GMT, Axel Boldt-Christmas wrote: >> Maybe this is ok, but I want to look at it more. The reason these functions started out in codeCache is because they looked like other functions in codeCache. > > The encapsulation is about defining an API for deoptimization which can enforce invariants and be safer to use. > ```C++ > // A DeoptimizationContext provides an API for deoptimizing CompileMethods > // The contract for using a DeoptimizationContext is as follows > // The context is active from the DeoptimizationContext objects creating > // until deoptimize() is called on the object. > // While the context is active, > // * no safepoint may be taken > // * any interaction with the context object must be done under > // the Compile_lock > // * deoptimize() must be called > // While the context is inactive > // * only interaction with the DeoptimizationContext object may > // calls to enqueued() and its destruction > > The idea with the API is that the logic of how compiled methods are selected is done in a context which wants to use the API, like class redefinition, class dependency changes, method handles, call site changes etc. > The goal was to move all the deoptimization logic from the codeCache to deoptimization. The JTMTI code got moved to jvmtiRedefineClasses as it had separate JVMTI specific logic. Storing old methods, etc. But I think some of the code that got moved from codeCache to deoptimization should/could be moved to instanceKlass, method, dependencies etc. as well. > The reason I only moved the JVMTI code is because it had side effects(separate from deoptimization). While all the other were only help functions which made dependency traversal easier. > > The only reason I feel reluctance about moving the JVMTI code to deoptimization is because it then must be old_compiled_method_table aware. > > But if you have some reason why it should be in deoptimization I would like to know. Okay, I looked at the change to jvmtiRedefineClasses.cpp in context and I like where you moved it. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From cjplummer at openjdk.org Fri Aug 26 20:45:55 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 26 Aug 2022 20:45:55 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 20:13:28 GMT, Serguei Spitsyn wrote: > If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. > > The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. > It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. > > The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. > > The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. > > The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. > > The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. test/hotspot/jtreg/serviceability/jvmti/vthread/GetSetLocalTest/libGetSetLocalTest.cpp line 316: > 314: Values values1 = { NULL, NULL, 2, 3L, (jfloat)4.2F, (jdouble)5.500000047683716 }; > 315: // jthread cthread = at_event ? get_carrier_thread(jvmti, jni, get_current_thread(jvmti, jni)) > 316: // : get_carrier_thread(jvmti, jni, vthread); Is there a reason to keep this around? ------------- PR: https://git.openjdk.org/jdk/pull/10051 From sspitsyn at openjdk.org Fri Aug 26 21:31:01 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 26 Aug 2022 21:31:01 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 20:42:01 GMT, Chris Plummer wrote: >> If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. >> >> The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. >> It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. >> >> The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. >> >> The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. >> >> The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. >> >> The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. > > test/hotspot/jtreg/serviceability/jvmti/vthread/GetSetLocalTest/libGetSetLocalTest.cpp line 316: > >> 314: Values values1 = { NULL, NULL, 2, 3L, (jfloat)4.2F, (jdouble)5.500000047683716 }; >> 315: // jthread cthread = at_event ? get_carrier_thread(jvmti, jni, get_current_thread(jvmti, jni)) >> 316: // : get_carrier_thread(jvmti, jni, vthread); > > Is there a reason to keep this around? You are right. Will remove this. ------------- PR: https://git.openjdk.org/jdk/pull/10051 From sspitsyn at openjdk.org Fri Aug 26 21:33:13 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 26 Aug 2022 21:33:13 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals [v2] In-Reply-To: References: Message-ID: > If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. > > The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. > It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. > > The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. > > The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. > > The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. > > The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: remove unneeded commented lines in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10051/files - new: https://git.openjdk.org/jdk/pull/10051/files/56fcb6ea..7033bcb6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10051&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10051&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10051.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10051/head:pull/10051 PR: https://git.openjdk.org/jdk/pull/10051 From kbarrett at openjdk.org Fri Aug 26 23:56:54 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 26 Aug 2022 23:56:54 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v2] In-Reply-To: References: <55UCDLv71g3p2WruG3x2ihLvFAjtA1HTGHLod1uI-RY=.0295efe2-af4b-47d9-a68e-d2be1bb21af0@github.com> Message-ID: <_W7PqPWOIhnY7My2_4vqvjWyEtcT26wX13fe0hvTlrM=.081d6b11-5bfd-4332-aba1-5eafe85821ce@github.com> On Fri, 26 Aug 2022 08:34:58 GMT, Jatin Bhateja wrote: >> I took John's code and made various (I think) improvements: >> https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:reverse-bits?expand=1 > > constexpr enables compiler to bypass usual in-lining constraints and inline the method body if all the arguments are constants at compile time under an assumption that IR pallet will be constant folded to a single value, in given context JIT compiler uses reverse_bit utility to constant fold Reverse IR node with constant inputs. Thus technically constexpr will not have much impact here. This is being proposed as a general utility, available for use in other contexts. That makes constexpr support very much appropriate. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From dlong at openjdk.org Sat Aug 27 00:05:53 2022 From: dlong at openjdk.org (Dean Long) Date: Sat, 27 Aug 2022 00:05:53 GMT Subject: RFR: 8292694: x86_64 c2i/i2c adapters may use more stack space than necessary In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 03:08:20 GMT, Dean Long wrote: > The c2i adapter includes the return address in the alignment calculation, making %rsp always mis-aligned according to the ABI. > > The i2c adapter aligns "extrawords" even though %rsp is aligned later, and the incoming stack is not guaranteed to be aligned. Thanks Vladimir. ------------- PR: https://git.openjdk.org/jdk/pull/10034 From dlong at openjdk.org Sat Aug 27 00:10:48 2022 From: dlong at openjdk.org (Dean Long) Date: Sat, 27 Aug 2022 00:10:48 GMT Subject: RFR: 8292694: x86_64 c2i/i2c adapters may use more stack space than necessary In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 03:08:20 GMT, Dean Long wrote: > The c2i adapter includes the return address in the alignment calculation, making %rsp always mis-aligned according to the ABI. > > The i2c adapter aligns "extrawords" even though %rsp is aligned later, and the incoming stack is not guaranteed to be aligned. I included generate_Continuation_doYield_entry() changes by mistake. I will revert those. ------------- PR: https://git.openjdk.org/jdk/pull/10034 From dlong at openjdk.org Sat Aug 27 00:21:07 2022 From: dlong at openjdk.org (Dean Long) Date: Sat, 27 Aug 2022 00:21:07 GMT Subject: RFR: 8292694: x86_64 c2i/i2c adapters may use more stack space than necessary [v2] In-Reply-To: References: Message-ID: > The c2i adapter includes the return address in the alignment calculation, making %rsp always mis-aligned according to the ABI. > > The i2c adapter aligns "extrawords" even though %rsp is aligned later, and the incoming stack is not guaranteed to be aligned. Dean Long has updated the pull request incrementally with one additional commit since the last revision: revert change to generate_Continuation_doYield_entry ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10034/files - new: https://git.openjdk.org/jdk/pull/10034/files/d6a27a77..30a65c8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10034&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10034&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10034/head:pull/10034 PR: https://git.openjdk.org/jdk/pull/10034 From kvn at openjdk.org Sat Aug 27 00:21:07 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 27 Aug 2022 00:21:07 GMT Subject: RFR: 8292694: x86_64 c2i/i2c adapters may use more stack space than necessary [v2] In-Reply-To: References: Message-ID: On Sat, 27 Aug 2022 00:17:42 GMT, Dean Long wrote: >> The c2i adapter includes the return address in the alignment calculation, making %rsp always mis-aligned according to the ABI. >> >> The i2c adapter aligns "extrawords" even though %rsp is aligned later, and the incoming stack is not guaranteed to be aligned. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > revert change to generate_Continuation_doYield_entry Yes, I was wandering about generate_Continuation_doYield_entry(). Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10034 From cjplummer at openjdk.org Sat Aug 27 00:30:51 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 27 Aug 2022 00:30:51 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals [v2] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 21:33:13 GMT, Serguei Spitsyn wrote: >> If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. >> >> The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. >> It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. >> >> The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. >> >> The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. >> >> The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. >> >> The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove unneeded commented lines in test Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/10051 From kbarrett at openjdk.org Sat Aug 27 00:55:38 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 27 Aug 2022 00:55:38 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v3] In-Reply-To: References: Message-ID: <-IKLdUDd8RCr0jo2Qlk4ta6uIcLarJkERU8IWI7Kp3M=.1ab734c8-31d1-4924-8469-6139fed211a3@github.com> On Fri, 26 Aug 2022 19:11:55 GMT, John R Rose wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8291649: Incorporating code changes from Kim and John. > > test/hotspot/gtest/opto/test_moveBits.cpp line 77: > >> 75: } >> 76: >> 77: // here is some object code to look at: > > Here's a more useful comment: > > > // Here is some object code to look at if we want to do a manual > // study. One could find the build file named test_moveBits.o.cmdline > // and hand-edit the command line to produce assembly code in > // test_moveBits.s. > // > // Or, given the two empty "fence functions", one could do a > // quick scan like this: > // > // $ objdump -D $(find build/*release -name test_moveBits.o) \ > // | sed -n /start_code_quality/,/end_code_quality/p \ > // | egrep -B10 bswap # or grep -B20 cfi_endproc > > void start_code_quality_moveBits() { } > > int16_t code_quality_reverse_bytes_16(int16_t x) { > ? > > int64_t code_quality_reverse_bits_64(int64_t x) { > return reverse_bits(x); // should compile to andq/shrq with 64-bit masks > } > > void end_code_quality_moveBits() { } I pushed a small fix, and added @rose00 above suggestion to my mentioned above. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From yadongwang at openjdk.org Sat Aug 27 15:25:57 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Sat, 27 Aug 2022 15:25:57 GMT Subject: RFR: 8293007: riscv: optimize nmethod entry barrier Message-ID: https://bugs.openjdk.org/browse/JDK-8290700 introduced a faster nmethod entry barrier: a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. Porting loom and generational ZGC are both under development in progress in riscv port project, and we brought the similar modification to make things smooth. Tier1 passed on unmatched. ------------- Commit messages: - fix whitespace - 8293007: riscv: optimize nmethod entry barrier Changes: https://git.openjdk.org/jdk/pull/10056/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10056&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293007 Stats: 282 lines in 16 files changed: 210 ins; 27 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/10056.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10056/head:pull/10056 PR: https://git.openjdk.org/jdk/pull/10056 From jbhateja at openjdk.org Sat Aug 27 16:58:48 2022 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sat, 27 Aug 2022 16:58:48 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v4] In-Reply-To: References: Message-ID: > Hi, > > This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. > A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8291649: Incorporating further refinements from Kim. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9987/files - new: https://git.openjdk.org/jdk/pull/9987/files/629c584e..ed21c38d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9987&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9987&range=02-03 Stats: 43 lines in 2 files changed: 15 ins; 6 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/9987.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9987/head:pull/9987 PR: https://git.openjdk.org/jdk/pull/9987 From jbhateja at openjdk.org Sat Aug 27 17:01:33 2022 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sat, 27 Aug 2022 17:01:33 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v4] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 18:27:34 GMT, Vladimir Kozlov wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8291649: Incorporating further refinements from Kim. > > I got failures in my testing. I posted them in bug report. Hi @vnkozlov , Please re-verify the latest version through oracle's test framework. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From kbarrett at openjdk.org Sun Aug 28 02:29:14 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 28 Aug 2022 02:29:14 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v4] In-Reply-To: References: Message-ID: On Sat, 27 Aug 2022 16:58:48 GMT, Jatin Bhateja wrote: >> Hi, >> >> This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. >> A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8291649: Incorporating further refinements from Kim. Looks good, other than the changes to subnode.cpp. Those also look good to me, but my knowledge in that part of the code is very limited, so you shouldn't count me as a reviewer for that part. I think you should probably add @rose00 and me as contributors. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9987 From dholmes at openjdk.org Mon Aug 29 00:10:59 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Aug 2022 00:10:59 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v2] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 14:21:51 GMT, Stefan Karlsson wrote: >> Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. >> >> This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. >> >> We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. >> >> I'd like to suggest that we use a convention to specify what we want. This is the current proposal: >> >> // Guide to the suffixes used in the format specifiers for integers: >> // - print the decimal value: 745565 >> // _X - print as hexadecimal, without leading 0s: 0x12345 >> // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >> // _H - print as hexadecimal, without 0x prefix >> // _W(w) - prints w sized string with the given value right >> // adjusted. Use -w to print left adjusted. >> // >> // Note that the PTR format specifiers print using 0x with leading zeros, >> // just like the _X_0 version for integers. >> >> >> The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Fix Shenandoah > The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. Why? If we are printing ptr values then PTR_FORMAT seems appropriate, even if they match an integer format. (And yes we have to cast the ptrs to int using p2i but that is just because of compiler limitations/issues ... which raises the recurring old question of "have we finally reached a point where we can use %p cross-platform?") ------------- PR: https://git.openjdk.org/jdk/pull/10042 From dholmes at openjdk.org Mon Aug 29 00:36:12 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Aug 2022 00:36:12 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Fri, 26 Aug 2022 17:07:54 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > include mutexLocker.hpp for minimal build. Hi Coleen, Probably due to my lack of understanding of the existing code I found this conversion very hard to follow. A number of comments below. Thanks. src/hotspot/share/classfile/protectionDomainCache.cpp line 42: > 40: #include "utilities/resourceHash.hpp" > 41: > 42: unsigned int ProtectionDomainCacheTable::compute_hash(const WeakHandle& protection_domain) { Why are we now using `WeakHandle` everywhere? src/hotspot/share/classfile/protectionDomainCache.cpp line 43: > 41: > 42: unsigned int ProtectionDomainCacheTable::compute_hash(const WeakHandle& protection_domain) { > 43: return (unsigned int)(protection_domain.resolve()->identity_hash()); And if it is a `WeakHandle` can't `resolve` now return NULL? src/hotspot/share/classfile/protectionDomainCache.cpp line 50: > 48: } > 49: > 50: ResourceHashtable 160: // Purge any deleted entries outside of the SystemDictionary_lock. > 161: purge_deleted_entries(); > 162: int oops_removed = purge_entries_from_table(); Maybe add comment `int oops_removed = purge_entries_from_table(); // reacquires SD lock` otherwise it gives the false impression this is done lock-free. src/hotspot/share/classfile/protectionDomainCache.cpp line 168: > 166: } > 167: > 168: void ProtectionDomainCacheTable::print_on(outputStream* st) { It is a little disconcerting that `print_on` can no longer be a `const` function! src/hotspot/share/classfile/protectionDomainCache.cpp line 186: > 184: > 185: // The object_no_keepalive() call peeks at the phantomly reachable oop without > 186: // keeping it alive. This is okay to do in the VM thread state if it is not You don't call `object_no_keepalive()` any more src/hotspot/share/classfile/protectionDomainCache.cpp line 202: > 200: // Keep entry alive > 201: (void)wk->resolve(); > 202: return *wk; Can't this be factored out of the if-else as `wk` is always the right entry to resolve and return? ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Mon Aug 29 01:57:24 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Aug 2022 01:57:24 GMT Subject: RFR: 8293012: ConstantPool::print_on can crash if _cache is NULL Message-ID: Please review this simple fix to avoid a crash when debugging the constant pool. Testing: tier1 sanity Thanks, David ------------- Commit messages: - 8293012: ConstantPool::print_on can crash if _cache is NULL Changes: https://git.openjdk.org/jdk/pull/10059/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10059&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293012 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10059.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10059/head:pull/10059 PR: https://git.openjdk.org/jdk/pull/10059 From shade at openjdk.org Mon Aug 29 05:53:58 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 29 Aug 2022 05:53:58 GMT Subject: RFR: 8293012: ConstantPool::print_on can crash if _cache is NULL In-Reply-To: References: Message-ID: <67vyxdViSpsRvvB6KRsRy1NtzYtQxwkmdR-iGoWgQEM=.24751802-c1a8-4d4d-a968-7b8d34abe065@github.com> On Mon, 29 Aug 2022 01:51:20 GMT, David Holmes wrote: > Please review this simple fix to avoid a crash when debugging the constant pool. > > Testing: tier1 sanity > > Thanks, > David Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10059 From stefank at openjdk.org Mon Aug 29 06:29:22 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 29 Aug 2022 06:29:22 GMT Subject: RFR: 8292697: ZGC: Hangs when almost out of metaspace memory [v2] In-Reply-To: <1xAJmoZVDBsIB4S6DK7bS26QwuCqEHNQWaD_L_4Muj0=.8c586a41-17d0-4bc5-943c-26172b8573fb@github.com> References: <54k4QZxdzCTj29jsLcnWtlZ5HtXxN4Zl7X4aqUmgObQ=.1ddad8cd-3ead-4356-8346-821fa0ca7aa1@github.com> <1xAJmoZVDBsIB4S6DK7bS26QwuCqEHNQWaD_L_4Muj0=.8c586a41-17d0-4bc5-943c-26172b8573fb@github.com> Message-ID: <1ueGjLpK5cLIJu6zk5Eqd5NBNFiv5FKV7NC3KHrEDnM=.166768cc-b1f0-4c3d-bbf8-9afc317baad5@github.com> On Fri, 26 Aug 2022 16:50:08 GMT, Thomas Stuefe wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test text > > src/hotspot/share/memory/metaspace.cpp line 998: > >> 996: } >> 997: >> 998: void Metaspace::purge(bool classes_unloaded) { > > Would it not have been more logical to heave both `MetaspaceCritical_lock` and `MetaspaceCriticalAllocation::process();` out of this function? As it is, `Metaspace::purge`, called with false, is now a no-op that only does things on behalf of the GC. It has nothing to do with the functioning of the allocator. I understand what you mean. On the other hand, if you take a look at Metaspace::allocate, it does quite a lot more than being an allocator, for example, it calls into the GC code (which performs the other side of the metaspace critical allocations). I wouldn't be opposed if anyone wanted to restructure this. ------------- PR: https://git.openjdk.org/jdk/pull/9985 From rehn at openjdk.org Mon Aug 29 06:34:11 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 29 Aug 2022 06:34:11 GMT Subject: RFR: 8293012: ConstantPool::print_on can crash if _cache is NULL In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 01:51:20 GMT, David Holmes wrote: > Please review this simple fix to avoid a crash when debugging the constant pool. > > Testing: tier1 sanity > > Thanks, > David Thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10059 From stefank at openjdk.org Mon Aug 29 07:02:08 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 29 Aug 2022 07:02:08 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com> References: <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com> Message-ID: On Fri, 26 Aug 2022 17:56:41 GMT, Ashutosh Mehra wrote: > @stefank @fisk I see this code [1] which indicates ZGC does not require barriers at all. I would appreciate if either of you can provide inputs on how does ZGC handles the scenario where the previously reachable object O1 is now reachable only from another object O2 allocated after marking has started. How would O1 be marked by ZGC in such case? This seems to be the scenario we are hitting in the context of loom code during the freeze process and shenandoah IU mode fails to handle it. > > [1] > > https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1299 This is our thinking w.r.t ZGC: 1) ZGC only returns memory from what we call "allocating" ZPages. Such pages are never part of an on-going marking cycle, and therefore don't need any barriers. 2) There's no safepoint *after* the memory has been allocated via `chunk_oop = allocator.allocate(); // can safepoint` So, when we reach the line you linked to, we are guaranteed that we don't need to perform any GC barriers on that object. Now, for Shenandoah IU mode, AFAIU (drawing parallels to CMS), the raw initializing stores are problematic, because you don't register those oops anywhere: // fields are uninitialized chunk->set_parent_raw(_cont.last_nonempty_chunk()); chunk->set_cont_raw(_cont.continuation()); You can also see how that comment about the fields are uninitialized, refers to SATB marking, and most-likely uses that as a rationale for skipping store barriers. In Generational ZGC, we also introduced store barriers. It's not similar to IU, but you can see how we had to changed from a raw store, to a store with a barrier: https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/runtime/continuationFreezeThaw.cpp // Allocate the chunk. // // This might safepoint while allocating, but all safepointing due to // instrumentation have been deferred. This property is important for // some GCs, as this ensures that the allocated object is in the young // generation / newly allocated memory. StackChunkAllocator allocator(klass, size_in_words, current, stack_size, _cont, _jvmti_event_collector); stackChunkOop chunk = allocator.allocate(); if (chunk == nullptr) { return nullptr; // OOME } ... #if INCLUDE_ZGC if (UseZGC) { // fields are uninitialized chunk->set_parent_access(_cont.last_nonempty_chunk()); chunk->set_cont_access(_cont.continuation()); ZStackChunkGCData::initialize(chunk); assert(!chunk->requires_barriers(), "ZGC always allocates in the young generation"); _barriers = false; } else #endif ------------- PR: https://git.openjdk.org/jdk/pull/9982 From thartmann at openjdk.org Mon Aug 29 07:35:10 2022 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 29 Aug 2022 07:35:10 GMT Subject: RFR: 8292694: x86_64 c2i/i2c adapters may use more stack space than necessary [v2] In-Reply-To: References: Message-ID: On Sat, 27 Aug 2022 00:21:07 GMT, Dean Long wrote: >> The c2i adapter includes the return address in the alignment calculation, making %rsp always mis-aligned according to the ABI. >> >> The i2c adapter aligns "extrawords" even though %rsp is aligned later, and the incoming stack is not guaranteed to be aligned. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > revert change to generate_Continuation_doYield_entry Looks good. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.org/jdk/pull/10034 From stefank at openjdk.org Mon Aug 29 07:44:13 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 29 Aug 2022 07:44:13 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v2] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 00:07:18 GMT, David Holmes wrote: > > The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. > > Why? If we are printing ptr values then PTR_FORMAT seems appropriate, even if they match an integer format. (And yes we have to cast the ptrs to int using p2i but that is just because of compiler limitations/issues ... which raises the recurring old question of "have we finally reached a point where we can use %p cross-platform?") I think you misunderstood this. I didn't remove PTR_FORMAT. I removed PTR32_FORMAT and PTR64_FORMAT, which were used to print integers with the same format as PTR_FORMAT. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From pli at openjdk.org Mon Aug 29 08:09:14 2022 From: pli at openjdk.org (Pengfei Li) Date: Mon, 29 Aug 2022 08:09:14 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN [v3] In-Reply-To: References: Message-ID: > Recently, an igvn infinite loop issue was reported. Git bisection shows > it appears after our JDK-8289996 patch. But after that patch is backed > out, we find similar test still fails. We have attached a jtreg case to > reproduce this issue. > > The ideal graph of the problematic method has a `MulINode` multiplying a > `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` > moves the constant input to the right hand side. And `Ideal()` function > in its parent class `MulNode` has the similar logic. In some code paths, > `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, > `MulINode` and `MulNode` use different ways to check constant. One calls > `type->singleton()` and the other calls `node->find_int_con(val)` which > accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` > can be evaluated to a constant, the two inputs of the `MulNode` will be > swapped back and forth in `Ideal()` calls. It eventually causes the igvn > infinite loop issue. > > This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` > because it's enough to do this by calling `MulNode::Ideal()`. We also do > some code cleanup in this patch as we have done in JDK-8289996. > > Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. Pengfei Li has updated the pull request incrementally with one additional commit since the last revision: Make the code more readable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9820/files - new: https://git.openjdk.org/jdk/pull/9820/files/7272ce10..1e455e31 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9820&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9820&range=01-02 Stats: 16 lines in 1 file changed: 2 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9820.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9820/head:pull/9820 PR: https://git.openjdk.org/jdk/pull/9820 From stefank at openjdk.org Mon Aug 29 08:24:10 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 29 Aug 2022 08:24:10 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v2] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 07:40:40 GMT, Stefan Karlsson wrote: > (And yes we have to cast the ptrs to int using p2i but that is just because of compiler limitations/issues ... which raises the recurring old question of "have we finally reached a point where we can use %p cross-platform?") One motivation for using PTR_FORMAT instead of %p, is to get consistent output on all platforms. I ran the following on different OSes: tty->print_cr("%p " PTR_FORMAT, (void*)0x12345678, (uintptr_t)0x12345678); And the result is: Linux: 0x12345678 0x0000000012345678 macOS: 0x12345678 0x0000000012345678 Win: 0x0000000012345678 0x0000000012345678 I also tested getting zero padding on Linux, but the compiler informs me that that's not allowed: `error: '0' flag used with '%p' gnu_printf format"`. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From fyang at openjdk.org Mon Aug 29 08:33:35 2022 From: fyang at openjdk.org (Fei Yang) Date: Mon, 29 Aug 2022 08:33:35 GMT Subject: RFR: 8293007: riscv: optimize nmethod entry barrier In-Reply-To: References: Message-ID: On Sat, 27 Aug 2022 14:54:18 GMT, Yadong Wang wrote: > https://bugs.openjdk.org/browse/JDK-8290700 introduced a faster nmethod entry barrier: a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. > Porting loom and generational ZGC are both under development in progress in riscv port project, and we brought the similar modification to make things smooth. > > Tier1 passed on unmatched. The riscv-specific code changes look fine. And I see the changes made to hotspot shared code are small and are guarded with #if defined(RISCV), which is the same as how aarch64 does, this should be safe and won't affect other platforms. BTW: I also performed tier2 hotspot & jdk test on riscv64-linux unmatched machine, result looks good. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10056 From aboldtch at openjdk.org Mon Aug 29 08:35:58 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 29 Aug 2022 08:35:58 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v9] In-Reply-To: References: Message-ID: > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > _Update_ > --- > Testing after 11d9dd2: Oracle platforms tier 1-5 Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Add asserts and comments - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Add context active assert - Cleanup comment - Add list optimization - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Rename deoptimize_done enum value - Add missing code from list revert - Initial draft new terminology - ... and 19 more: https://git.openjdk.org/jdk/compare/512fee1d...c35f5ed6 ------------- Changes: https://git.openjdk.org/jdk/pull/9655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=08 Stats: 753 lines in 27 files changed: 351 ins; 282 del; 120 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From chagedorn at openjdk.org Mon Aug 29 08:42:19 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 29 Aug 2022 08:42:19 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN [v3] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 08:09:14 GMT, Pengfei Li wrote: >> Recently, an igvn infinite loop issue was reported. Git bisection shows >> it appears after our JDK-8289996 patch. But after that patch is backed >> out, we find similar test still fails. We have attached a jtreg case to >> reproduce this issue. >> >> The ideal graph of the problematic method has a `MulINode` multiplying a >> `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` >> moves the constant input to the right hand side. And `Ideal()` function >> in its parent class `MulNode` has the similar logic. In some code paths, >> `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, >> `MulINode` and `MulNode` use different ways to check constant. One calls >> `type->singleton()` and the other calls `node->find_int_con(val)` which >> accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` >> can be evaluated to a constant, the two inputs of the `MulNode` will be >> swapped back and forth in `Ideal()` calls. It eventually causes the igvn >> infinite loop issue. >> >> This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` >> because it's enough to do this by calling `MulNode::Ideal()`. We also do >> some code cleanup in this patch as we have done in JDK-8289996. >> >> Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. > > Pengfei Li has updated the pull request incrementally with one additional commit since the last revision: > > Make the code more readable Thanks for doing the updates! Apart from some other minor things, it looks good to me! src/hotspot/share/opto/mulnode.cpp line 337: > 335: // Check for power-of-2 multiply, then try the regular MulNode::Ideal > 336: Node *MulLNode::Ideal(PhaseGVN *phase, bool can_reshape) { > 337: // Swap constant to right This comment can now also be removed as already done in `MulINode::Ideal()`. src/hotspot/share/opto/mulnode.cpp line 338: > 336: Node *MulLNode::Ideal(PhaseGVN *phase, bool can_reshape) { > 337: // Swap constant to right > 338: jlong con = in(2)->find_long_con(0); Can also be a `const` as done in `MulINode::Ideal()`. src/hotspot/share/opto/mulnode.cpp line 346: > 344: > 345: // Now we have a constant Node on the right and the constant in con. > 346: if (con == CONST64(1)) { I guess you can also remove `CONST64` here and directly write `con == 1` (as you've already done for `con == 0`). ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9820 From fjiang at openjdk.org Mon Aug 29 08:45:38 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Mon, 29 Aug 2022 08:45:38 GMT Subject: RFR: 8293007: riscv: optimize nmethod entry barrier In-Reply-To: References: Message-ID: On Sat, 27 Aug 2022 14:54:18 GMT, Yadong Wang wrote: > https://bugs.openjdk.org/browse/JDK-8290700 introduced a faster nmethod entry barrier: a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. > Porting loom and generational ZGC are both under development in progress in riscv port project, and we brought the similar modification to make things smooth. > > Tier1 passed on unmatched. Looks good. (Not a JDK Reviewer) ------------- Marked as reviewed by fjiang (Author). PR: https://git.openjdk.org/jdk/pull/10056 From duke at openjdk.org Mon Aug 29 08:47:31 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 29 Aug 2022 08:47:31 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v5] In-Reply-To: References: Message-ID: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com> > May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? > > This PR does 3 things: > > * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot > * Adds some new utilities for writing multi-threaded tests. > * Adds some tests for MRSW Mutex using these new utilities > > The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 > > [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9838/files - new: https://git.openjdk.org/jdk/pull/9838/files/da53eaa2..5bb6a520 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9838&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9838&range=03-04 Stats: 64 lines in 3 files changed: 22 ins; 21 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/9838.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9838/head:pull/9838 PR: https://git.openjdk.org/jdk/pull/9838 From duke at openjdk.org Mon Aug 29 08:47:31 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 29 Aug 2022 08:47:31 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v4] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 13:06:01 GMT, Johan Sj?l?n wrote: >> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? >> >> This PR does 3 things: >> >> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot >> * Adds some new utilities for writing multi-threaded tests. >> * Adds some tests for MRSW Mutex using these new utilities >> >> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 >> >> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > > Johan Sj?l?n has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Fix tests for updated threadHelper > - Remove outdated threadHelper > - Update documentation > - Fix outdated headers and remove dead code > - Review comments > - Implement MRSWMutex Latest addresses most of Kim's review comments. It also makes the `current` thread optional, allowing it to be null. This is mainly useful if the lock is used very early in initialization. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From pli at openjdk.org Mon Aug 29 08:50:53 2022 From: pli at openjdk.org (Pengfei Li) Date: Mon, 29 Aug 2022 08:50:53 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN [v3] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 08:38:47 GMT, Christian Hagedorn wrote: >> Pengfei Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Make the code more readable > > Thanks for doing the updates! Apart from some other minor things, it looks good to me! @chhagedorn Thanks for your review. Currently this patch has conflicts with jdk master. I will try a merge and then do the minor fixes as you suggested. ------------- PR: https://git.openjdk.org/jdk/pull/9820 From yadongwang at openjdk.org Mon Aug 29 09:18:52 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Mon, 29 Aug 2022 09:18:52 GMT Subject: RFR: 8293007: riscv: optimize nmethod entry barrier In-Reply-To: References: Message-ID: On Sat, 27 Aug 2022 14:54:18 GMT, Yadong Wang wrote: > https://bugs.openjdk.org/browse/JDK-8290700 introduced a faster nmethod entry barrier: a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. > Porting loom and generational ZGC are both under development in progress in riscv port project, and we brought the similar modification to make things smooth. > > Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures. Better have another review, maybe @shipilev please? ------------- PR: https://git.openjdk.org/jdk/pull/10056 From sspitsyn at openjdk.org Mon Aug 29 09:27:23 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 29 Aug 2022 09:27:23 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals [v2] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 21:33:13 GMT, Serguei Spitsyn wrote: >> If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. >> >> The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. >> It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. >> >> The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. >> >> The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. >> >> The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. >> >> The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove unneeded commented lines in test Thank you for review, Chris! ------------- PR: https://git.openjdk.org/jdk/pull/10051 From shade at openjdk.org Mon Aug 29 11:29:11 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 29 Aug 2022 11:29:11 GMT Subject: RFR: 8293007: riscv: optimize nmethod entry barrier In-Reply-To: References: Message-ID: On Sat, 27 Aug 2022 14:54:18 GMT, Yadong Wang wrote: > https://bugs.openjdk.org/browse/JDK-8290700 introduced a faster nmethod entry barrier: a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. > Porting loom and generational ZGC are both under development in progress in riscv port project, and we brought the similar modification to make things smooth. > > Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures. Looks okay with minor comments. src/hotspot/cpu/riscv/gc/g1/g1BarrierSetAssembler_riscv.cpp line 161: > 159: __ bind(runtime); > 160: > 161: __ push_call_clobbered_registers(); So this looks like a bugfix? https://mail.openjdk.org/pipermail/riscv-port-dev/2022-August/000601.html The issue and PR should probably reflect that then. src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 192: > 190: > 191: void BarrierSetAssembler::clear_patching_epoch() { > 192: _patching_epoch = 0; Don't we want `Atomic::store(&_patching_epoch, 0)` here? src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 224: > 222: // which means there isn't really any need for any fencing for neither > 223: // data nor instruction modification happening concurrently. The > 224: // instruction patching is synchronized with glocal icache_flush() by "global"? src/hotspot/cpu/riscv/gc/shared/barrierSetNMethod_riscv.cpp line 204: > 202: // are read in the opposite order, such that the load of the nmethod guard > 203: // acquires the patching epoch. This way, the guard is guaranteed to block > 204: // entries to the nmethod, util it has safely published the requirement for "until"? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10056 From pli at openjdk.org Mon Aug 29 11:34:02 2022 From: pli at openjdk.org (Pengfei Li) Date: Mon, 29 Aug 2022 11:34:02 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN [v4] In-Reply-To: References: Message-ID: > Recently, an igvn infinite loop issue was reported. Git bisection shows > it appears after our JDK-8289996 patch. But after that patch is backed > out, we find similar test still fails. We have attached a jtreg case to > reproduce this issue. > > The ideal graph of the problematic method has a `MulINode` multiplying a > `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` > moves the constant input to the right hand side. And `Ideal()` function > in its parent class `MulNode` has the similar logic. In some code paths, > `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, > `MulINode` and `MulNode` use different ways to check constant. One calls > `type->singleton()` and the other calls `node->find_int_con(val)` which > accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` > can be evaluated to a constant, the two inputs of the `MulNode` will be > swapped back and forth in `Ideal()` calls. It eventually causes the igvn > infinite loop issue. > > This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` > because it's enough to do this by calling `MulNode::Ideal()`. We also do > some code cleanup in this patch as we have done in JDK-8289996. > > Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. Pengfei Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Add some minor fixes - Merge branch 'master' into igvn - Make the code more readable - Reword some comments - 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN Recently, an igvn infinite loop issue was reported. Git bisection shows it appears after our JDK-8289996 patch. But after that patch is backed out, we find similar test still fails. We have attached a jtreg case to reproduce this issue. The ideal graph of the problematic method has a `MulINode` multiplying a `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` moves the constant input to the right hand side. And `Ideal()` function in its parent class `MulNode` has the similar logic. In some code paths, `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, `MulINode` and `MulNode` use different ways to check constant. One calls `type->singleton()` and the other calls `node->find_int_con(val)` which accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` can be evaluated to a constant, the two inputs of the `MulNode` will be swapped back and forth in `Ideal()` calls. It eventually causes the igvn infinite loop issue. This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` because it's enough to do this by calling `MulNode::Ideal()`. We also do some code cleanup in this patch as we have done in JDK-8289996. Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. ------------- Changes: https://git.openjdk.org/jdk/pull/9820/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9820&range=03 Stats: 101 lines in 3 files changed: 81 ins; 4 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/9820.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9820/head:pull/9820 PR: https://git.openjdk.org/jdk/pull/9820 From chagedorn at openjdk.org Mon Aug 29 12:09:27 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 29 Aug 2022 12:09:27 GMT Subject: RFR: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN [v4] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 11:34:02 GMT, Pengfei Li wrote: >> Recently, an igvn infinite loop issue was reported. Git bisection shows >> it appears after our JDK-8289996 patch. But after that patch is backed >> out, we find similar test still fails. We have attached a jtreg case to >> reproduce this issue. >> >> The ideal graph of the problematic method has a `MulINode` multiplying a >> `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` >> moves the constant input to the right hand side. And `Ideal()` function >> in its parent class `MulNode` has the similar logic. In some code paths, >> `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, >> `MulINode` and `MulNode` use different ways to check constant. One calls >> `type->singleton()` and the other calls `node->find_int_con(val)` which >> accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` >> can be evaluated to a constant, the two inputs of the `MulNode` will be >> swapped back and forth in `Ideal()` calls. It eventually causes the igvn >> infinite loop issue. >> >> This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` >> because it's enough to do this by calling `MulNode::Ideal()`. We also do >> some code cleanup in this patch as we have done in JDK-8289996. >> >> Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. > > Pengfei Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Add some minor fixes > - Merge branch 'master' into igvn > - Make the code more readable > - Reword some comments > - 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN > > Recently, an igvn infinite loop issue was reported. Git bisection shows > it appears after our JDK-8289996 patch. But after that patch is backed > out, we find similar test still fails. We have attached a jtreg case to > reproduce this issue. > > The ideal graph of the problematic method has a `MulINode` multiplying a > `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` > moves the constant input to the right hand side. And `Ideal()` function > in its parent class `MulNode` has the similar logic. In some code paths, > `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, > `MulINode` and `MulNode` use different ways to check constant. One calls > `type->singleton()` and the other calls `node->find_int_con(val)` which > accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` > can be evaluated to a constant, the two inputs of the `MulNode` will be > swapped back and forth in `Ideal()` calls. It eventually causes the igvn > infinite loop issue. > > This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` > because it's enough to do this by calling `MulNode::Ideal()`. We also do > some code cleanup in this patch as we have done in JDK-8289996. > > Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. That looks good, thanks for adding the suggestions! ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9820 From dholmes at openjdk.org Mon Aug 29 12:12:10 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Aug 2022 12:12:10 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v2] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 07:40:40 GMT, Stefan Karlsson wrote: > I think you misunderstood this. I didn't remove PTR_FORMAT. I removed PTR32_FORMAT and PTR64_FORMAT, which were used to print integers with the same format as PTR_FORMAT. At least the first few cases all look like ptr's to me: stackptr_t, codeptr_t, p2i(x) ?? ------------- PR: https://git.openjdk.org/jdk/pull/10042 From dholmes at openjdk.org Mon Aug 29 12:19:06 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Aug 2022 12:19:06 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v2] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 08:22:04 GMT, Stefan Karlsson wrote: > One motivation for using PTR_FORMAT instead of %p, is to get consistent output on all platforms. Yes that has always been the problem, but I wondered whether this issue was perhaps finally resolved. Based on your results we seem closer - they all have leading 0x - but they still differ in leading zeroes. I have a recollection now that someone tried using %p fairly recently (ie last 12-24 months) and also discovered this. Kind of sad that something so conceptually simple has proven to be so difficult to get right. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From coleenp at openjdk.org Mon Aug 29 12:22:16 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 29 Aug 2022 12:22:16 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Fri, 26 Aug 2022 17:07:54 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > include mutexLocker.hpp for minimal build. Thanks for reading through this. I was going to make a larger change, then changed my mind. This conversion is limited. It is able to take advantage of the ability to copy WeakHandle without side effects, so that we don't have to store ProtectionDomainCacheEntry into the pd_set linked list, which makes it nicer. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Mon Aug 29 12:22:22 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 29 Aug 2022 12:22:22 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Mon, 29 Aug 2022 00:12:36 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> include mutexLocker.hpp for minimal build. > > src/hotspot/share/classfile/protectionDomainCache.cpp line 42: > >> 40: #include "utilities/resourceHash.hpp" >> 41: >> 42: unsigned int ProtectionDomainCacheTable::compute_hash(const WeakHandle& protection_domain) { > > Why are we now using `WeakHandle` everywhere? WeakHandle is the object we're storing as in the hashtable. It also turns out to be the key. > src/hotspot/share/classfile/protectionDomainCache.cpp line 43: > >> 41: >> 42: unsigned int ProtectionDomainCacheTable::compute_hash(const WeakHandle& protection_domain) { >> 43: return (unsigned int)(protection_domain.resolve()->identity_hash()); > > And if it is a `WeakHandle` can't `resolve` now return NULL? compute_hash() is always called on a live WeakHandle so will never return null. > src/hotspot/share/classfile/protectionDomainCache.cpp line 50: > >> 48: } >> 49: >> 50: ResourceHashtable > I am struggling to understand what the key and values types are in this hashtable ??? WeakHandle is the key and the value in this hashtable. We need to match the WeakHandle in the input by value (see equals function), but we also want to return the WeakHandle to store in to the pd_set list in the DictionaryEntry. > src/hotspot/share/classfile/protectionDomainCache.cpp line 162: > >> 160: // Purge any deleted entries outside of the SystemDictionary_lock. >> 161: purge_deleted_entries(); >> 162: int oops_removed = purge_entries_from_table(); > > Maybe add comment > > `int oops_removed = purge_entries_from_table(); // reacquires SD lock` > > otherwise it gives the false impression this is done lock-free. Ok. > src/hotspot/share/classfile/protectionDomainCache.cpp line 168: > >> 166: } >> 167: >> 168: void ProtectionDomainCacheTable::print_on(outputStream* st) { > > It is a little disconcerting that `print_on` can no longer be a `const` function! It's static, so it can't. > src/hotspot/share/classfile/protectionDomainCache.cpp line 186: > >> 184: >> 185: // The object_no_keepalive() call peeks at the phantomly reachable oop without >> 186: // keeping it alive. This is okay to do in the VM thread state if it is not > > You don't call `object_no_keepalive()` any more This one (not the one I removed), is called by dictionary.cpp - the pd_set is a linked list of ProtectionDomainEntry, where we don't keep the WeakHandle alive when looking at the value. > src/hotspot/share/classfile/protectionDomainCache.cpp line 202: > >> 200: // Keep entry alive >> 201: (void)wk->resolve(); >> 202: return *wk; > > Can't this be factored out of the if-else as `wk` is always the right entry to resolve and return? Yes, that works. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Mon Aug 29 12:24:33 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 29 Aug 2022 12:24:33 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v4] In-Reply-To: References: Message-ID: > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: David's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10043/files - new: https://git.openjdk.org/jdk/pull/10043/files/842b30ab..ac67b187 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=02-03 Stats: 9 lines in 1 file changed: 3 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From stefank at openjdk.org Mon Aug 29 12:47:06 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 29 Aug 2022 12:47:06 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v2] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 12:08:27 GMT, David Holmes wrote: > > I think you misunderstood this. I didn't remove PTR_FORMAT. I removed PTR32_FORMAT and PTR64_FORMAT, which were used to print integers with the same format as PTR_FORMAT. > > At least the first few cases all look like ptr's to me: stackptr_t, codeptr_t, p2i(x) ?? OK, now I understand what you mean. Right, those should be changed to PTR_FORMAT. I'll change that, but I can't compile for AIX, so I hope someone else can test this for me (alt. fix this post-integration). ------------- PR: https://git.openjdk.org/jdk/pull/10042 From pli at openjdk.org Mon Aug 29 13:10:28 2022 From: pli at openjdk.org (Pengfei Li) Date: Mon, 29 Aug 2022 13:10:28 GMT Subject: Integrated: 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 09:33:58 GMT, Pengfei Li wrote: > Recently, an igvn infinite loop issue was reported. Git bisection shows > it appears after our JDK-8289996 patch. But after that patch is backed > out, we find similar test still fails. We have attached a jtreg case to > reproduce this issue. > > The ideal graph of the problematic method has a `MulINode` multiplying a > `PhiNode` by a `ConINode`. For better optimizations, `MulINode::Ideal()` > moves the constant input to the right hand side. And `Ideal()` function > in its parent class `MulNode` has the similar logic. In some code paths, > `MulINode::Ideal()` calls `MulNode::Ideal()`. The problem here is that, > `MulINode` and `MulNode` use different ways to check constant. One calls > `type->singleton()` and the other calls `node->find_int_con(val)` which > accepts constant in `PhiNode`. So in some corner cases where a `PhiNode` > can be evaluated to a constant, the two inputs of the `MulNode` will be > swapped back and forth in `Ideal()` calls. It eventually causes the igvn > infinite loop issue. > > This patch removes the `swap_edges()` logic in `MulINode` and `MulLNode` > because it's enough to do this by calling `MulNode::Ideal()`. We also do > some code cleanup in this patch as we have done in JDK-8289996. > > Tested hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1. This pull request has now been integrated. Changeset: a88a9e34 Author: Pengfei Li URL: https://git.openjdk.org/jdk/commit/a88a9e344f66bca21f3a01dbbcea19b52af14865 Stats: 101 lines in 3 files changed: 81 ins; 4 del; 16 mod 8291466: C2: assert(false) failed: infinite loop in PhaseIterGVN::transform_old with -XX:+StressIGVN Reviewed-by: roland, chagedorn ------------- PR: https://git.openjdk.org/jdk/pull/9820 From stefank at openjdk.org Mon Aug 29 13:12:05 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 29 Aug 2022 13:12:05 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v3] In-Reply-To: References: Message-ID: > Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. > > This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. > > We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. > > I'd like to suggest that we use a convention to specify what we want. This is the current proposal: > > // Guide to the suffixes used in the format specifiers for integers: > // - print the decimal value: 745565 > // _X - print as hexadecimal, without leading 0s: 0x12345 > // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 > // _H - print as hexadecimal, without 0x prefix > // _W(w) - prints w sized string with the given value right > // adjusted. Use -w to print left adjusted. > // > // Note that the PTR format specifiers print using 0x with leading zeros, > // just like the _X_0 version for integers. > > > The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Use PTR_FORMAT in AIX code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10042/files - new: https://git.openjdk.org/jdk/pull/10042/files/b19c7d0e..0f3bdd26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10042.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10042/head:pull/10042 PR: https://git.openjdk.org/jdk/pull/10042 From yadongwang at openjdk.org Mon Aug 29 14:13:00 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Mon, 29 Aug 2022 14:13:00 GMT Subject: RFR: 8293007: riscv: optimize nmethod entry barrier In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 11:15:30 GMT, Aleksey Shipilev wrote: >> https://bugs.openjdk.org/browse/JDK-8290700 introduced a faster nmethod entry barrier: a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. >> Porting loom and generational ZGC are both under development in progress in riscv port project, and we brought the similar modification to make things smooth. >> >> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures. > > src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 192: > >> 190: >> 191: void BarrierSetAssembler::clear_patching_epoch() { >> 192: _patching_epoch = 0; > > Don't we want `Atomic::store(&_patching_epoch, 0)` here? We can do a relax clear here, because clear_patching_epoch() was only called by arm_all_nmethods(), which happened always in the safepoint. ------------- PR: https://git.openjdk.org/jdk/pull/10056 From yadongwang at openjdk.org Mon Aug 29 14:41:12 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Mon, 29 Aug 2022 14:41:12 GMT Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2] In-Reply-To: References: Message-ID: > The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping. > Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre(). > > Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth. > > Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. > > Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures. Yadong Wang has updated the pull request incrementally with two additional commits since the last revision: - fix typo - fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10056/files - new: https://git.openjdk.org/jdk/pull/10056/files/8ef56f73..2bcc0331 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10056&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10056&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10056.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10056/head:pull/10056 PR: https://git.openjdk.org/jdk/pull/10056 From yadongwang at openjdk.org Mon Aug 29 14:41:15 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Mon, 29 Aug 2022 14:41:15 GMT Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 11:14:20 GMT, Aleksey Shipilev wrote: >> Yadong Wang has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix typo >> - fix typo > > src/hotspot/cpu/riscv/gc/g1/g1BarrierSetAssembler_riscv.cpp line 161: > >> 159: __ bind(runtime); >> 160: >> 161: __ push_call_clobbered_registers(); > > So this looks like a bugfix? https://mail.openjdk.org/pipermail/riscv-port-dev/2022-August/000601.html > > The issue and PR should probably reflect that then. Agree. I have modified issue and PR. > src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 224: > >> 222: // which means there isn't really any need for any fencing for neither >> 223: // data nor instruction modification happening concurrently. The >> 224: // instruction patching is synchronized with glocal icache_flush() by > > "global"? Thanks. Fixed. > src/hotspot/cpu/riscv/gc/shared/barrierSetNMethod_riscv.cpp line 204: > >> 202: // are read in the opposite order, such that the load of the nmethod guard >> 203: // acquires the patching epoch. This way, the guard is guaranteed to block >> 204: // entries to the nmethod, util it has safely published the requirement for > > "until"? Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/10056 From yadongwang at openjdk.org Mon Aug 29 14:41:17 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Mon, 29 Aug 2022 14:41:17 GMT Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2] In-Reply-To: References: Message-ID: <2Nxt4JwZvcFnhpvVDcm-H4Mi4uvDS21swh4IaIKcNiI=.31d0a7d4-f3dd-4454-b108-aea15cac2de3@github.com> On Mon, 29 Aug 2022 14:34:13 GMT, Yadong Wang wrote: >> src/hotspot/cpu/riscv/gc/shared/barrierSetNMethod_riscv.cpp line 204: >> >>> 202: // are read in the opposite order, such that the load of the nmethod guard >>> 203: // acquires the patching epoch. This way, the guard is guaranteed to block >>> 204: // entries to the nmethod, util it has safely published the requirement for >> >> "until"? > > Fixed. Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/10056 From shade at openjdk.org Mon Aug 29 15:00:01 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 29 Aug 2022 15:00:01 GMT Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 14:41:12 GMT, Yadong Wang wrote: >> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping. >> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre(). >> >> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth. >> >> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. >> >> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures. > > Yadong Wang has updated the pull request incrementally with two additional commits since the last revision: > > - fix typo > - fix typo Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10056 From shade at openjdk.org Mon Aug 29 15:00:06 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 29 Aug 2022 15:00:06 GMT Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 14:09:28 GMT, Yadong Wang wrote: >> src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 192: >> >>> 190: >>> 191: void BarrierSetAssembler::clear_patching_epoch() { >>> 192: _patching_epoch = 0; >> >> Don't we want `Atomic::store(&_patching_epoch, 0)` here? > > We can do a relax clear here, because clear_patching_epoch() was only called by arm_all_nmethods(), which happened always in the safepoint. Allright then. ------------- PR: https://git.openjdk.org/jdk/pull/10056 From aboldtch at openjdk.org Mon Aug 29 15:24:48 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 29 Aug 2022 15:24:48 GMT Subject: RFR: 8293035: Cleanup MacroAssembler::movoop code patching logic aarch64 riscv Message-ID: Cleanup MacroAssembler::movoop logic with respect to code patching on aarch64 and riscv. Remove the `bool immediate` argument as it is only used with the value `true` in `void MacroAssembler::movoop(Register dst, jobject obj, bool immediate)` Make comments and logic more clear and easier to read. Testing: osx, linux aarch64 tier 1-3 ------------- Commit messages: - 8293035: Cleanup MacroAssembler::movoop code patching logic aarch64 riscv Changes: https://git.openjdk.org/jdk/pull/10065/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10065&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293035 Stats: 35 lines in 12 files changed: 6 ins; 11 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/10065.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10065/head:pull/10065 PR: https://git.openjdk.org/jdk/pull/10065 From eosterlund at openjdk.org Mon Aug 29 15:38:07 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 29 Aug 2022 15:38:07 GMT Subject: RFR: 8293035: Cleanup MacroAssembler::movoop code patching logic aarch64 riscv In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 15:16:23 GMT, Axel Boldt-Christmas wrote: > Cleanup MacroAssembler::movoop logic with respect to code patching on aarch64 and riscv. > > Remove the `bool immediate` argument as it is only used with the value `true` in `void MacroAssembler::movoop(Register dst, jobject obj, bool immediate)` > > Make comments and logic more clear and easier to read. > > Testing: osx, linux aarch64 tier 1-3 Looks good. Thanks for fixing! ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/10065 From eosterlund at openjdk.org Mon Aug 29 16:10:28 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 29 Aug 2022 16:10:28 GMT Subject: RFR: 8290025: Remove the Sweeper [v13] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 15:33:53 GMT, Martin Doerr wrote: > Some more information about the "Out of space in CodeCache for adapters" issue: The test was running with less than 240MB ReservedCodeCacheSize. The VM doesn't enable SegmentedCodeCache in this case. Seems like the new implementation doesn't make sure we have enough space for adapters without SegmentedCodeCache, but we're not using this case in production. May still be a a good enhancement. Hmm. Good observation. Without segmented code cache, these issues are indeed more prevalent by nature. I'm not sure what the use case is for running without segmented code cache. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From eosterlund at openjdk.org Mon Aug 29 16:13:11 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 29 Aug 2022 16:13:11 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: References: <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com> Message-ID: On Mon, 29 Aug 2022 06:58:37 GMT, Stefan Karlsson wrote: > > @stefank @fisk I see this code [1] which indicates ZGC does not require barriers at all. I would appreciate if either of you can provide inputs on how does ZGC handles the scenario where the previously reachable object O1 is now reachable only from another object O2 allocated after marking has started. How would O1 be marked by ZGC in such case? This seems to be the scenario we are hitting in the context of loom code during the freeze process and shenandoah IU mode fails to handle it. > > > > > > [1] > > > > > > https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1299 > > > > This is our thinking w.r.t ZGC: > > 1) ZGC only returns memory from what we call "allocating" ZPages. Such pages are never part of an on-going marking cycle, and therefore don't need any barriers. > > 2) There's no safepoint *after* the memory has been allocated via `chunk_oop = allocator.allocate(); // can safepoint` > > > > So, when we reach the line you linked to, we are guaranteed that we don't need to perform any GC barriers on that object. > > > > Now, for Shenandoah IU mode, AFAIU (drawing parallels to CMS), the raw initializing stores are problematic, because you don't register those oops anywhere: > > ``` > > // fields are uninitialized > > chunk->set_parent_raw(_cont.last_nonempty_chunk()); > > chunk->set_cont_raw(_cont.continuation()); > > ``` > > > > You can also see how that comment about the fields are uninitialized, refers to SATB marking, and most-likely uses that as a rationale for skipping store barriers. > > > > In Generational ZGC, we also introduced store barriers. It's not similar to IU, but you can see how we had to changed from a raw store, to a store with a barrier: > > https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/runtime/continuationFreezeThaw.cpp > > > > ``` > > // Allocate the chunk. > > // > > // This might safepoint while allocating, but all safepointing due to > > // instrumentation have been deferred. This property is important for > > // some GCs, as this ensures that the allocated object is in the young > > // generation / newly allocated memory. > > StackChunkAllocator allocator(klass, size_in_words, current, stack_size, _cont, _jvmti_event_collector); > > stackChunkOop chunk = allocator.allocate(); > > > > if (chunk == nullptr) { > > return nullptr; // OOME > > } > > ... > > #if INCLUDE_ZGC > > if (UseZGC) { > > // fields are uninitialized > > chunk->set_parent_access(_cont.last_nonempty_chunk()); > > chunk->set_cont_access(_cont.continuation()); > > ZStackChunkGCData::initialize(chunk); > > > > assert(!chunk->requires_barriers(), "ZGC always allocates in the young generation"); > > _barriers = false; > > } else > > #endif > > ``` The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not. ------------- PR: https://git.openjdk.org/jdk/pull/9982 From vlivanov at openjdk.org Mon Aug 29 17:12:01 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 29 Aug 2022 17:12:01 GMT Subject: RFR: 8292878: x86: Make scratch register usage explicit in assembler code [v4] In-Reply-To: <75euD5SuLprNP7TWtaG57I-ePW0vkSh77mo2qEarevI=.f012660b-febc-409c-99fd-731b482fb31b@github.com> References: <75euD5SuLprNP7TWtaG57I-ePW0vkSh77mo2qEarevI=.f012660b-febc-409c-99fd-731b482fb31b@github.com> Message-ID: <_sbLJhUd3BdQ3Zr9djztIvwhyBa8i-YD7nPyr54Le_g=.3fa77f28-b558-4f54-a987-579e5d8564a3@github.com> On Thu, 25 Aug 2022 22:19:14 GMT, Vladimir Ivanov wrote: >> Improve MacroAssembler API and make scratch register usages explicit at use sites. >> >> Different parts of JVM have different assumptions about scratch registers and >> implicit assumptions in MacroAssembler makes it harder to reason about the >> correctness of generated code. >> >> Most of scratch register usages relate to `AddressLiteral` on x86_64. In such case the argument is turned into a default one (with `noreg` as a default) and implementation asserts that scratch register should be provided when the address is not guaranteed to be always reachable. >> >> Otherwise, scratch register argument is required to be explicitly provided. >> >> The only case left (mostly) intact is `call(AddressLiteral)`, but I switched it from `rscratch` (`r10`) to `rax`. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 (w/ -XX:+-ForceUnreachable) >> - [x] x86_32 build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > x86_32 Thanks for the review, Vladimir. @shipilev Aleksey, do you plan to look into x86_32-specific changes? Otherwise, I'll integrate the patch. ------------- PR: https://git.openjdk.org/jdk/pull/10003 From vlivanov at openjdk.org Mon Aug 29 17:26:20 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 29 Aug 2022 17:26:20 GMT Subject: RFR: 8293036: x86_64: Move Continuation-related stub methods to MacroAssembler Message-ID: <1M2F-T10O-tziQRrEx1e_vFWu98boRiqbjg7D0XPEoc=.cbe3298a-bc24-44f3-ae99-76e9bbc69f59@github.com> Move Continuation-related methods from `stubGenerator_x86_64.cpp` under `MacroAssembler`. Testing: hs-tier1 - hs-tier2 ------------- Commit messages: - include - fix - move Changes: https://git.openjdk.org/jdk/pull/10066/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10066&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293036 Stats: 238 lines in 4 files changed: 126 ins; 105 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10066.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10066/head:pull/10066 PR: https://git.openjdk.org/jdk/pull/10066 From dlong at openjdk.org Mon Aug 29 19:42:27 2022 From: dlong at openjdk.org (Dean Long) Date: Mon, 29 Aug 2022 19:42:27 GMT Subject: RFR: 8292694: x86_64 c2i/i2c adapters may use more stack space than necessary [v2] In-Reply-To: References: Message-ID: On Sat, 27 Aug 2022 00:21:07 GMT, Dean Long wrote: >> The c2i adapter includes the return address in the alignment calculation, making %rsp always mis-aligned according to the ABI. >> >> The i2c adapter aligns "extrawords" even though %rsp is aligned later, and the incoming stack is not guaranteed to be aligned. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > revert change to generate_Continuation_doYield_entry Thanks Tobias. ------------- PR: https://git.openjdk.org/jdk/pull/10034 From dlong at openjdk.org Mon Aug 29 19:42:27 2022 From: dlong at openjdk.org (Dean Long) Date: Mon, 29 Aug 2022 19:42:27 GMT Subject: Integrated: 8292694: x86_64 c2i/i2c adapters may use more stack space than necessary In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 03:08:20 GMT, Dean Long wrote: > The c2i adapter includes the return address in the alignment calculation, making %rsp always mis-aligned according to the ABI. > > The i2c adapter aligns "extrawords" even though %rsp is aligned later, and the incoming stack is not guaranteed to be aligned. This pull request has now been integrated. Changeset: adb3d4f1 Author: Dean Long URL: https://git.openjdk.org/jdk/commit/adb3d4f14af1974e7fc9461eb59f98131f0d33f7 Stats: 79 lines in 3 files changed: 44 ins; 25 del; 10 mod 8292694: x86_64 c2i/i2c adapters may use more stack space than necessary Reviewed-by: kvn, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/10034 From dlong at openjdk.org Mon Aug 29 20:37:11 2022 From: dlong at openjdk.org (Dean Long) Date: Mon, 29 Aug 2022 20:37:11 GMT Subject: RFR: 8293036: x86_64: Move Continuation-related stub methods to MacroAssembler In-Reply-To: <1M2F-T10O-tziQRrEx1e_vFWu98boRiqbjg7D0XPEoc=.cbe3298a-bc24-44f3-ae99-76e9bbc69f59@github.com> References: <1M2F-T10O-tziQRrEx1e_vFWu98boRiqbjg7D0XPEoc=.cbe3298a-bc24-44f3-ae99-76e9bbc69f59@github.com> Message-ID: On Mon, 29 Aug 2022 17:17:22 GMT, Vladimir Ivanov wrote: > Move Continuation-related methods from `stubGenerator_x86_64.cpp` under `MacroAssembler`. > > Testing: hs-tier1 - hs-tier2 It looks good, but I'm curious, what's the motivation? ------------- Marked as reviewed by dlong (Reviewer). PR: https://git.openjdk.org/jdk/pull/10066 From iklam at openjdk.org Mon Aug 29 20:52:21 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 29 Aug 2022 20:52:21 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v5] In-Reply-To: References: Message-ID: > Some CDS functions are always compiled, even when CDS is not enabled (e.g., for the minimal VM). > > This RFE puts some of the obvious ones inside `#if INCLUDE_CDS` blocks. > > Note: my goal is not to make the minimal VM as small as possible. But rather, I don't want to put `#if INCLUDE_CDS` inside each of those functions that access a CDS-only feature. (E.g., `ConstantPoolCache::save_for_archive`, which accesses `_initial_entries`, which is declared only when CDS is enabled). 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' of https://github.com/openjdk/jdk into 8292891-ifdef-out-some-cds-functions - fixed typo - @dholmes-ora and @coleenp comments - @calvinccheung comments - 8292891: ifdef-out some CDS-only functions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10010/files - new: https://git.openjdk.org/jdk/pull/10010/files/5f8bcd39..7f80b1a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10010&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10010&range=03-04 Stats: 15931 lines in 452 files changed: 6249 ins; 7912 del; 1770 mod Patch: https://git.openjdk.org/jdk/pull/10010.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10010/head:pull/10010 PR: https://git.openjdk.org/jdk/pull/10010 From vlivanov at openjdk.org Mon Aug 29 21:01:15 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 29 Aug 2022 21:01:15 GMT Subject: RFR: 8293036: x86_64: Move Continuation-related stub methods to MacroAssembler In-Reply-To: <1M2F-T10O-tziQRrEx1e_vFWu98boRiqbjg7D0XPEoc=.cbe3298a-bc24-44f3-ae99-76e9bbc69f59@github.com> References: <1M2F-T10O-tziQRrEx1e_vFWu98boRiqbjg7D0XPEoc=.cbe3298a-bc24-44f3-ae99-76e9bbc69f59@github.com> Message-ID: <2W1QHR6w0ctY5XRnBzUv5aMhrCEEUXCqPNklCkEkAZo=.51de02d3-d63a-444c-a959-45536d1a9607@github.com> On Mon, 29 Aug 2022 17:17:22 GMT, Vladimir Ivanov wrote: > Move Continuation-related methods from `stubGenerator_x86_64.cpp` under `MacroAssembler`. > > Testing: hs-tier1 - hs-tier2 Thanks for the review, Dean. > It looks good, but I'm curious, what's the motivation? It's a worthwhile cleanup per se, but it'll also benefit forthcoming cleanups in `stubGenerator_x86_64.cpp`. ------------- PR: https://git.openjdk.org/jdk/pull/10066 From iklam at openjdk.org Mon Aug 29 23:20:10 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 29 Aug 2022 23:20:10 GMT Subject: RFR: 8292891: ifdef-out some CDS-only functions [v4] In-Reply-To: References: Message-ID: <4Xy5K8QePlle9Jb_Xk2s09pxoRTBjafrfEr6cto4Cw8=.69236a2a-a7c8-4fca-9931-aa360badcd64@github.com> On Fri, 26 Aug 2022 16:29:25 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed typo > > Marked as reviewed by ccheung (Reviewer). Thanks @calvinccheung @coleenp @dholmes-ora for the review! ------------- PR: https://git.openjdk.org/jdk/pull/10010 From iklam at openjdk.org Mon Aug 29 23:24:08 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 29 Aug 2022 23:24:08 GMT Subject: Integrated: 8292891: ifdef-out some CDS-only functions In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 22:27:48 GMT, Ioi Lam wrote: > Some CDS functions are always compiled, even when CDS is not enabled (e.g., for the minimal VM). > > This RFE puts some of the obvious ones inside `#if INCLUDE_CDS` blocks. > > Note: my goal is not to make the minimal VM as small as possible. But rather, I don't want to put `#if INCLUDE_CDS` inside each of those functions that access a CDS-only feature. (E.g., `ConstantPoolCache::save_for_archive`, which accesses `_initial_entries`, which is declared only when CDS is enabled). This pull request has now been integrated. Changeset: 40b0ed56 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/40b0ed565720fa75fc23e1a8f26e7cfe5feebf8f Stats: 64 lines in 16 files changed: 41 ins; 19 del; 4 mod 8292891: ifdef-out some CDS-only functions Reviewed-by: coleenp, ccheung, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/10010 From dholmes at openjdk.org Tue Aug 30 00:16:30 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Aug 2022 00:16:30 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v5] In-Reply-To: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com> References: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com> Message-ID: On Mon, 29 Aug 2022 08:47:31 GMT, Johan Sj?l?n wrote: >> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? >> >> This PR does 3 things: >> >> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot >> * Adds some new utilities for writing multi-threaded tests. >> * Adds some tests for MRSW Mutex using these new utilities >> >> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 >> >> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Review comments src/hotspot/share/utilities/readWriteLock.hpp line 91: > 89: ~ReadWriteLock() = default; > 90: > 91: void write_lock(Thread* current = Thread::current_or_null()); I'm not seeing the motivation for allowing current to be null with these latest changes. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From dholmes at openjdk.org Tue Aug 30 00:16:31 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Aug 2022 00:16:31 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v5] In-Reply-To: References: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com> Message-ID: On Tue, 30 Aug 2022 00:11:16 GMT, David Holmes wrote: >> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > src/hotspot/share/utilities/readWriteLock.hpp line 91: > >> 89: ~ReadWriteLock() = default; >> 90: >> 91: void write_lock(Thread* current = Thread::current_or_null()); > > I'm not seeing the motivation for allowing current to be null with these latest changes. To be clear, you will only ever get a null if someone passes it in explicitly as Thread::current_or_null() should never be able to return null in the contexts you would use this RWL. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From kbarrett at openjdk.org Tue Aug 30 00:31:51 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 30 Aug 2022 00:31:51 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v3] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 13:12:05 GMT, Stefan Karlsson wrote: >> Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. >> >> This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. >> >> We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. >> >> I'd like to suggest that we use a convention to specify what we want. This is the current proposal: >> >> // Guide to the suffixes used in the format specifiers for integers: >> // - print the decimal value: 745565 >> // _X - print as hexadecimal, without leading 0s: 0x12345 >> // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >> // _H - print as hexadecimal, without 0x prefix >> // _W(w) - prints w sized string with the given value right >> // adjusted. Use -w to print left adjusted. >> // >> // Note that the PTR format specifiers print using 0x with leading zeros, >> // just like the _X_0 version for integers. >> >> >> The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Use PTR_FORMAT in AIX code Looks good. Nearly(?) all of my comments are about pre-existing things that might be best handled via followup RFEs. src/hotspot/share/cds/filemap.cpp line 335: > 333: st->print_cr("- serialized_data_offset: " SIZE_FORMAT_X, _serialized_data_offset); > 334: st->print_cr("- heap_begin: " INTPTR_FORMAT, p2i(_heap_begin)); > 335: st->print_cr("- heap_end: " INTPTR_FORMAT, p2i(_heap_end)); Pre-existing: Seems like heap_begin and heap_end should be using `PTR_FORMAT`. Similarly a few lines above for narrow_oop_base (which appears twice?), and a few lines down for requested/mapped_base_address. There are some others like this in this file. src/hotspot/share/runtime/deoptimization.cpp line 1904: > 1902: > 1903: // Log a message > 1904: Events::log_deopt_message(current, "Uncommon trap: trap_request=" INT32_FORMAT_X_0 " fr.pc=" INTPTR_FORMAT " relative=" INTPTR_FORMAT, pre-existing: (first only) s/INTPTR_FORMAT/PTR_FORMAT/. src/hotspot/share/utilities/globalDefinitions.hpp line 99: > 97: // _H - print as hexadecimal, without 0x prefix > 98: // _W(w) - prints w sized string with the given value right > 99: // adjusted. Use -w to print left adjusted. pre-existing: The "width" values for "W" suffixed formatters probably ought to be in the expansion as "XSTR(width)" rather than "#width", to permit the use of a macro for the width value. src/hotspot/share/utilities/globalDefinitions.hpp line 133: > 131: // Format integers which change size between 32- and 64-bit. > 132: #define SSIZE_FORMAT "%" PRIdPTR > 133: #define SSIZE_FORMAT_W(width) "%" #width PRIdPTR SSIZE_FORMAT_W appears to be unused. src/hotspot/share/utilities/globalDefinitions.hpp line 134: > 132: #define SSIZE_FORMAT "%" PRIdPTR > 133: #define SSIZE_FORMAT_W(width) "%" #width PRIdPTR > 134: #define SIZE_FORMAT "%" PRIuPTR With C++14/C99, we can use "%zu" instead of SIZE_FORMAT and "%zd" instead of SSIZE_FORMAT. src/hotspot/share/utilities/globalDefinitions.hpp line 135: > 133: #define SSIZE_FORMAT_W(width) "%" #width PRIdPTR > 134: #define SIZE_FORMAT "%" PRIuPTR > 135: #define SIZE_FORMAT_X "0x%" PRIxPTR Some people might prefer to write "0x%zx" instead of SIZE_FORMAT_X. It's annoying that the "#" flag for "%x" only prints the leading "0x" for non-zero values. Who thought that was a good idea? Otherwise we could write "%#zx" instead of SIZE_FORMAT_X (4 characters instead of 17, including the break in the middle of the string for the macro). src/hotspot/share/utilities/globalDefinitions.hpp line 163: > 161: // Format pointers which change size between 32- and 64-bit. > 162: #ifdef _LP64 > 163: #define INTPTR_FORMAT "0x%016" PRIxPTR pre-existing: The naming of INTPTR_FORMAT is inconsistent with the other integer formatters because the "X_0" suffix is missing and padded hex printing is implicit. It's a (slightly shorter) syntactic synonym for the (not currently defined) INTX_FORMAT_X_0. While reviewing this change I noticed several uses of INTPTR_FORMAT that seemed like they should be PTR_FORMAT. I'm not entirely sure what the intended usage for INTPTR_FORMAT might be. I wonder what would be left after making a pass looking carefully at uses of INTPTR_FORMAT. src/hotspot/share/utilities/globalDefinitions.hpp line 169: > 167: #define PTR_FORMAT "0x%08" PRIxPTR > 168: #endif // _LP64 > 169: #define INTPTR_FORMAT_H_W(width) "%" #width PRIxPTR The naming of INTPTR_FORMAT_H_W is inconsistent with INTPTR_FORMAT. It seems only used in one area of Shenandoah code, where it seems like they should be using PTR_FORMAT, except they are trying to output fewer leading zeros. I'm somewhat inclined to say this doesn't belong in globalDefinitions.hpp at all; if they have specialized printing desirements they can define whatever they want themselves. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/10042 From kbarrett at openjdk.org Tue Aug 30 00:31:51 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 30 Aug 2022 00:31:51 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v2] In-Reply-To: References: Message-ID: <-JcsjOLcgiUAxDLHFe-0FcgqyhXW-9Xqr4A9nBikLzk=.c130c29d-eec2-4df2-9385-1bf0d7319508@github.com> On Mon, 29 Aug 2022 08:22:04 GMT, Stefan Karlsson wrote: > > (And yes we have to cast the ptrs to int using p2i but that is just because of compiler limitations/issues ... which raises the recurring old question of "have we finally reached a point where we can use %p cross-platform?") > > One motivation for using PTR_FORMAT instead of %p, is to get consistent output on all platforms. I ran the following on different OSes: > > ``` > tty->print_cr("%p " PTR_FORMAT, (void*)0x12345678, (uintptr_t)0x12345678); > ``` > > And the result is: > > ``` > Linux: 0x12345678 0x0000000012345678 > macOS: 0x12345678 0x0000000012345678 > Win: 0x0000000012345678 0x0000000012345678 > ``` > > I also tested getting zero padding on Linux, but the compiler informs me that that's not allowed: `error: '0' flag used with '%p' gnu_printf format"`. The description of "%p" says: "The value of the pointer is converted to a sequence of printing characters, in an implementation-defined manner." No flag/modifier support is specified for "%p", so using any is UB. And gcc prints nullptr as "(null)"! ------------- PR: https://git.openjdk.org/jdk/pull/10042 From dholmes at openjdk.org Tue Aug 30 00:55:54 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Aug 2022 00:55:54 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v3] In-Reply-To: References: Message-ID: <1doCSnH92SCk-jw02xk-SyDL2LaB1XQOtyJVrhiKjOk=.efaf478d-8960-4057-ab9e-a075e7b4dbee@github.com> On Mon, 29 Aug 2022 13:12:05 GMT, Stefan Karlsson wrote: >> Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. >> >> This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. >> >> We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. >> >> I'd like to suggest that we use a convention to specify what we want. This is the current proposal: >> >> // Guide to the suffixes used in the format specifiers for integers: >> // - print the decimal value: 745565 >> // _X - print as hexadecimal, without leading 0s: 0x12345 >> // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >> // _H - print as hexadecimal, without 0x prefix >> // _W(w) - prints w sized string with the given value right >> // adjusted. Use -w to print left adjusted. >> // >> // Note that the PTR format specifiers print using 0x with leading zeros, >> // just like the _X_0 version for integers. >> >> >> The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Use PTR_FORMAT in AIX code src/hotspot/share/code/codeHeapState.cpp line 1401: > 1399: ast->fill_to(19); > 1400: //---< blob offset from CodeHeap begin >--- > 1401: ast->print("(+" UINT32_FORMAT_X_0 ")", (unsigned int)((char*)this_blob-low_bound)); Took me a while to realize this was actually a ptr-diff ! ------------- PR: https://git.openjdk.org/jdk/pull/10042 From dholmes at openjdk.org Tue Aug 30 00:55:57 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Aug 2022 00:55:57 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v3] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 22:46:58 GMT, Kim Barrett wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Use PTR_FORMAT in AIX code > > src/hotspot/share/runtime/deoptimization.cpp line 1904: > >> 1902: >> 1903: // Log a message >> 1904: Events::log_deopt_message(current, "Uncommon trap: trap_request=" INT32_FORMAT_X_0 " fr.pc=" INTPTR_FORMAT " relative=" INTPTR_FORMAT, > > pre-existing: (first only) s/INTPTR_FORMAT/PTR_FORMAT/. I'm confused now about whether we use `p2i(x)` with `PTR_FORMAT` or `INTPTR_FORMAT`? `p2i` converts a pointer to an int so the resulting type should be `intptr_t` and so the format should be `INTPTR_FORMAT` - is that not so? > src/hotspot/share/utilities/globalDefinitions.hpp line 163: > >> 161: // Format pointers which change size between 32- and 64-bit. >> 162: #ifdef _LP64 >> 163: #define INTPTR_FORMAT "0x%016" PRIxPTR > > pre-existing: The naming of INTPTR_FORMAT is inconsistent with the other integer formatters because the "X_0" suffix is missing and padded hex printing is implicit. It's a (slightly shorter) syntactic synonym for the (not currently defined) INTX_FORMAT_X_0. While reviewing this change I noticed several uses of INTPTR_FORMAT that seemed like they should be PTR_FORMAT. I'm not entirely sure what the intended usage for INTPTR_FORMAT might be. I wonder what would be left after making a pass looking carefully at uses of INTPTR_FORMAT. See my related comment above. I think because of lack of %p, and possibly some typing issues we have general confusion about whether we can print pointers directly or whether we have to convert them to an integral type, ie intptr_t, first using p2i. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From fyang at openjdk.org Tue Aug 30 01:00:56 2022 From: fyang at openjdk.org (Fei Yang) Date: Tue, 30 Aug 2022 01:00:56 GMT Subject: RFR: 8292575: riscv: Represent Registers as values [v2] In-Reply-To: References: Message-ID: <1RYaQlISrhYH5OI6FGDoafB_T7Y_K3-jyMuMIPgCkKM=.a477fb05-80de-4c86-a80d-dee4875e0b2a@github.com> On Fri, 26 Aug 2022 02:49:17 GMT, Feilong Jiang wrote: >> Follow up [JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153) and [JDK-8292203](https://bugs.openjdk.org/browse/JDK-8292203), migrate away from pointer-based representation of Register values. >> >> It improves compile-time checking by forbidding implicit conversions between integrals and pointers. >> >> Testing: >> - hotspot/jdk tier1 on unmatched board >> - hotspot/jdk tier1 on qemu > > Feilong Jiang 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' of https://github.com/openjdk/jdk into riscv-register-rep > - Represent Registers as values src/hotspot/cpu/riscv/vmreg_riscv.inline.hpp line 33: > 31: } > 32: > 33: inline VMReg FloatRegister::FloatRegister::FloatRegisterImpl::as_VMReg() const { Shouldn't this be: inline VMReg FloatRegister::FloatRegisterImpl::as_VMReg() const? ------------- PR: https://git.openjdk.org/jdk/pull/9936 From dholmes at openjdk.org Tue Aug 30 01:01:38 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Aug 2022 01:01:38 GMT Subject: RFR: 8293012: ConstantPool::print_on can crash if _cache is NULL In-Reply-To: <67vyxdViSpsRvvB6KRsRy1NtzYtQxwkmdR-iGoWgQEM=.24751802-c1a8-4d4d-a968-7b8d34abe065@github.com> References: <67vyxdViSpsRvvB6KRsRy1NtzYtQxwkmdR-iGoWgQEM=.24751802-c1a8-4d4d-a968-7b8d34abe065@github.com> Message-ID: On Mon, 29 Aug 2022 05:50:38 GMT, Aleksey Shipilev wrote: >> Please review this simple fix to avoid a crash when debugging the constant pool. >> >> Testing: tier1 sanity >> >> Thanks, >> David > > Looks fine. Thanks for the reviews @shipilev and @robehn ! ------------- PR: https://git.openjdk.org/jdk/pull/10059 From dholmes at openjdk.org Tue Aug 30 01:01:38 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Aug 2022 01:01:38 GMT Subject: Integrated: 8293012: ConstantPool::print_on can crash if _cache is NULL In-Reply-To: References: Message-ID: <5YKi_qDMNijoWcEZDpfu8n7-89R5XzJhN5SWbcDIPxE=.1d72b9aa-396d-4eb0-8501-b1b94d0d54d3@github.com> On Mon, 29 Aug 2022 01:51:20 GMT, David Holmes wrote: > Please review this simple fix to avoid a crash when debugging the constant pool. > > Testing: tier1 sanity > > Thanks, > David This pull request has now been integrated. Changeset: 9424d6d4 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/9424d6d487db4ad0f6f671a8c33b8f169794fe25 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8293012: ConstantPool::print_on can crash if _cache is NULL Reviewed-by: shade, rehn ------------- PR: https://git.openjdk.org/jdk/pull/10059 From fjiang at openjdk.org Tue Aug 30 01:07:59 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 30 Aug 2022 01:07:59 GMT Subject: RFR: 8292575: riscv: Represent Registers as values [v3] In-Reply-To: References: Message-ID: > Follow up [JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153) and [JDK-8292203](https://bugs.openjdk.org/browse/JDK-8292203), migrate away from pointer-based representation of Register values. > > It improves compile-time checking by forbidding implicit conversions between integrals and pointers. > > Testing: > - hotspot/jdk tier1 on unmatched board > - hotspot/jdk tier1 on qemu Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: remove duplicate code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9936/files - new: https://git.openjdk.org/jdk/pull/9936/files/72e55d46..b9dbd6b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9936&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9936&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9936.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9936/head:pull/9936 PR: https://git.openjdk.org/jdk/pull/9936 From fjiang at openjdk.org Tue Aug 30 01:08:03 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 30 Aug 2022 01:08:03 GMT Subject: RFR: 8292575: riscv: Represent Registers as values [v2] In-Reply-To: <1RYaQlISrhYH5OI6FGDoafB_T7Y_K3-jyMuMIPgCkKM=.a477fb05-80de-4c86-a80d-dee4875e0b2a@github.com> References: <1RYaQlISrhYH5OI6FGDoafB_T7Y_K3-jyMuMIPgCkKM=.a477fb05-80de-4c86-a80d-dee4875e0b2a@github.com> Message-ID: On Tue, 30 Aug 2022 00:57:13 GMT, Fei Yang wrote: >> Feilong Jiang 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' of https://github.com/openjdk/jdk into riscv-register-rep >> - Represent Registers as values > > src/hotspot/cpu/riscv/vmreg_riscv.inline.hpp line 33: > >> 31: } >> 32: >> 33: inline VMReg FloatRegister::FloatRegister::FloatRegisterImpl::as_VMReg() const { > > Shouldn't this be: inline VMReg FloatRegister::FloatRegisterImpl::as_VMReg() const? Yes, fixed. ------------- PR: https://git.openjdk.org/jdk/pull/9936 From yadongwang at openjdk.org Tue Aug 30 01:20:23 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Tue, 30 Aug 2022 01:20:23 GMT Subject: Integrated: 8293007: riscv: failed to build after JDK-8290025 In-Reply-To: References: Message-ID: On Sat, 27 Aug 2022 14:54:18 GMT, Yadong Wang wrote: > The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping. > Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre(). > > Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth. > > Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. > > Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures. This pull request has now been integrated. Changeset: e016363b Author: Yadong Wang Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/e016363b54f1624e9ff4470803c6000d8fe91a7f Stats: 283 lines in 16 files changed: 210 ins; 27 del; 46 mod 8293007: riscv: failed to build after JDK-8290025 Reviewed-by: fyang, fjiang, shade ------------- PR: https://git.openjdk.org/jdk/pull/10056 From fyang at openjdk.org Tue Aug 30 01:22:05 2022 From: fyang at openjdk.org (Fei Yang) Date: Tue, 30 Aug 2022 01:22:05 GMT Subject: RFR: 8293035: Cleanup MacroAssembler::movoop code patching logic aarch64 riscv In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 15:16:23 GMT, Axel Boldt-Christmas wrote: > Cleanup MacroAssembler::movoop logic with respect to code patching on aarch64 and riscv. > > Remove the `bool immediate` argument as it is only used with the value `true` in `void MacroAssembler::movoop(Register dst, jobject obj, bool immediate)` > > Make comments and logic more clear and easier to read. > > Testing: osx, linux aarch64 tier 1-3 Thanks for taking care of riscv-specific part at the same time. I guess you might need some rework since https://github.com/openjdk/jdk/pull/10056 is integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10065 From fjiang at openjdk.org Tue Aug 30 01:24:17 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 30 Aug 2022 01:24:17 GMT Subject: RFR: 8292575: riscv: Represent Registers as values [v4] In-Reply-To: References: Message-ID: > Follow up [JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153) and [JDK-8292203](https://bugs.openjdk.org/browse/JDK-8292203), migrate away from pointer-based representation of Register values. > > It improves compile-time checking by forbidding implicit conversions between integrals and pointers. > > Testing: > - hotspot/jdk tier1 on unmatched board > - hotspot/jdk tier1 on qemu Feilong Jiang 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' of https://github.com/openjdk/jdk into riscv-register-rep - remove duplicate code - Merge branch 'master' of https://github.com/openjdk/jdk into riscv-register-rep - Represent Registers as values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9936/files - new: https://git.openjdk.org/jdk/pull/9936/files/b9dbd6b4..ba493543 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9936&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9936&range=02-03 Stats: 1623 lines in 101 files changed: 1195 ins; 150 del; 278 mod Patch: https://git.openjdk.org/jdk/pull/9936.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9936/head:pull/9936 PR: https://git.openjdk.org/jdk/pull/9936 From yzhu at openjdk.org Tue Aug 30 01:48:16 2022 From: yzhu at openjdk.org (Yanhong Zhu) Date: Tue, 30 Aug 2022 01:48:16 GMT Subject: RFR: 8292575: riscv: Represent Registers as values [v3] In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 01:07:59 GMT, Feilong Jiang wrote: >> Follow up [JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153) and [JDK-8292203](https://bugs.openjdk.org/browse/JDK-8292203), migrate away from pointer-based representation of Register values. >> >> It improves compile-time checking by forbidding implicit conversions between integrals and pointers. >> >> Testing: >> - hotspot/jdk tier1 on unmatched board >> - hotspot/jdk tier1 on qemu > > Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: > > remove duplicate code Looks good. ------------- Marked as reviewed by yzhu (Author). PR: https://git.openjdk.org/jdk/pull/9936 From kvn at openjdk.org Tue Aug 30 02:06:24 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 30 Aug 2022 02:06:24 GMT Subject: RFR: 8293036: x86_64: Move Continuation-related stub methods to MacroAssembler In-Reply-To: <1M2F-T10O-tziQRrEx1e_vFWu98boRiqbjg7D0XPEoc=.cbe3298a-bc24-44f3-ae99-76e9bbc69f59@github.com> References: <1M2F-T10O-tziQRrEx1e_vFWu98boRiqbjg7D0XPEoc=.cbe3298a-bc24-44f3-ae99-76e9bbc69f59@github.com> Message-ID: <3ViXcZ_TYw99nJ_13eeWErsLJmDLiG3GvQseUwV9Wug=.1a98f032-62ca-4b09-9551-e4b9601119e2@github.com> On Mon, 29 Aug 2022 17:17:22 GMT, Vladimir Ivanov wrote: > Move Continuation-related methods from `stubGenerator_x86_64.cpp` under `MacroAssembler`. > > Testing: hs-tier1 - hs-tier2 Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10066 From kvn at openjdk.org Tue Aug 30 02:13:14 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 30 Aug 2022 02:13:14 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v4] In-Reply-To: References: Message-ID: On Sat, 27 Aug 2022 16:58:48 GMT, Jatin Bhateja wrote: >> Hi, >> >> This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. >> A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8291649: Incorporating further refinements from Kim. I submitted new testing. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From yadongwang at openjdk.org Tue Aug 30 02:24:09 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Tue, 30 Aug 2022 02:24:09 GMT Subject: RFR: 8292575: riscv: Represent Registers as values [v4] In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 01:24:17 GMT, Feilong Jiang wrote: >> Follow up [JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153) and [JDK-8292203](https://bugs.openjdk.org/browse/JDK-8292203), migrate away from pointer-based representation of Register values. >> >> It improves compile-time checking by forbidding implicit conversions between integrals and pointers. >> >> Testing: >> - hotspot/jdk tier1 on unmatched board >> - hotspot/jdk tier1 on qemu > > Feilong Jiang 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' of https://github.com/openjdk/jdk into riscv-register-rep > - remove duplicate code > - Merge branch 'master' of https://github.com/openjdk/jdk into riscv-register-rep > - Represent Registers as values Marked as reviewed by yadongwang (Author). lgtm(not a reviewer) ------------- PR: https://git.openjdk.org/jdk/pull/9936 From fyang at openjdk.org Tue Aug 30 03:44:09 2022 From: fyang at openjdk.org (Fei Yang) Date: Tue, 30 Aug 2022 03:44:09 GMT Subject: RFR: 8292575: riscv: Represent Registers as values [v4] In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 01:24:17 GMT, Feilong Jiang wrote: >> Follow up [JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153) and [JDK-8292203](https://bugs.openjdk.org/browse/JDK-8292203), migrate away from pointer-based representation of Register values. >> >> It improves compile-time checking by forbidding implicit conversions between integrals and pointers. >> >> Testing: >> - hotspot/jdk tier1 on unmatched board >> - hotspot/jdk tier1 on qemu > > Feilong Jiang 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' of https://github.com/openjdk/jdk into riscv-register-rep > - remove duplicate code > - Merge branch 'master' of https://github.com/openjdk/jdk into riscv-register-rep > - Represent Registers as values Updated changes look good. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/9936 From kvn at openjdk.org Tue Aug 30 03:46:17 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 30 Aug 2022 03:46:17 GMT Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 09:15:26 GMT, Yadong Wang wrote: >> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping. >> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre(). >> >> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth. >> >> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. >> >> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures. > > Better have another review, maybe @shipilev please? @yadongw this broke aarch64 Zero build: ------------- PR: https://git.openjdk.org/jdk/pull/10056 From kim.barrett at oracle.com Tue Aug 30 04:11:05 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 30 Aug 2022 04:11:05 +0000 Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v3] In-Reply-To: References: Message-ID: > On Aug 29, 2022, at 8:55 PM, David Holmes wrote: > > On Mon, 29 Aug 2022 22:46:58 GMT, Kim Barrett wrote: > >>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Use PTR_FORMAT in AIX code >> >> src/hotspot/share/runtime/deoptimization.cpp line 1904: >> >>> 1902: >>> 1903: // Log a message >>> 1904: Events::log_deopt_message(current, "Uncommon trap: trap_request=" INT32_FORMAT_X_0 " fr.pc=" INTPTR_FORMAT " relative=" INTPTR_FORMAT, >> >> pre-existing: (first only) s/INTPTR_FORMAT/PTR_FORMAT/. > > I'm confused now about whether we use `p2i(x)` with `PTR_FORMAT` or `INTPTR_FORMAT`? `p2i` converts a pointer to an int so the resulting type should be `intptr_t` and so the format should be `INTPTR_FORMAT` - is that not so? I think PTR_FORMAT should always be used with the result of p2i ? we?re printing a pointer. I think using INTPTR_FORMAT with the result of p2i is a bug (though one that only affects code understanding, not execution). I think if we went through and fixed all of those misuses of INTPTR_FORMAT, some of the remaining uses of it might be more appropriately using something else, like one of the INTX_FORMAT variants. And I wonder what the residue from dealing with those might be - perhaps empty? From fjiang at openjdk.org Tue Aug 30 05:04:09 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 30 Aug 2022 05:04:09 GMT Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 09:15:26 GMT, Yadong Wang wrote: >> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping. >> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre(). >> >> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth. >> >> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. >> >> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures. > > Better have another review, maybe @shipilev please? > @yadongw this broke aarch64 Zero build: > > ``` > /workspace/open/src/hotspot/share/gc/shared/barrierSetNMethod.cpp: In member function 'void BarrierSetNMethod::arm_all_nmethods()': > /workspace/open/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:136:24: error: incomplete type 'BarrierSetAssembler' used in nested name specifier > 136 | BarrierSetAssembler::clear_patching_epoch(); > | ^~~~~~~~~~~~~~~~~~~~ > ``` Thanks for reporting this issue, I'm working on it and will submit a fixing PR later. ------------- PR: https://git.openjdk.org/jdk/pull/10056 From yadongwang at openjdk.org Tue Aug 30 05:11:04 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Tue, 30 Aug 2022 05:11:04 GMT Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 09:15:26 GMT, Yadong Wang wrote: >> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping. >> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre(). >> >> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth. >> >> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. >> >> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures. > > Better have another review, maybe @shipilev please? > @yadongw this broke aarch64 Zero build: > > ``` > /workspace/open/src/hotspot/share/gc/shared/barrierSetNMethod.cpp: In member function 'void BarrierSetNMethod::arm_all_nmethods()': > /workspace/open/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:136:24: error: incomplete type 'BarrierSetAssembler' used in nested name specifier > 136 | BarrierSetAssembler::clear_patching_epoch(); > | ^~~~~~~~~~~~~~~~~~~~ > ``` @vnkozlov Sorry for the problem. I missed the building/testing of zero, and we'll fix that right way. ------------- PR: https://git.openjdk.org/jdk/pull/10056 From thartmann at openjdk.org Tue Aug 30 05:22:05 2022 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 30 Aug 2022 05:22:05 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v4] In-Reply-To: References: Message-ID: On Sat, 27 Aug 2022 16:58:48 GMT, Jatin Bhateja wrote: >> Hi, >> >> This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. >> A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8291649: Incorporating further refinements from Kim. Does this fix [JDK-8293039](https://bugs.openjdk.org/browse/JDK-8293039) as well? ------------- PR: https://git.openjdk.org/jdk/pull/9987 From fjiang at openjdk.org Tue Aug 30 06:23:01 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 30 Aug 2022 06:23:01 GMT Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 14:41:12 GMT, Yadong Wang wrote: >> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping. >> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre(). >> >> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth. >> >> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. >> >> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures. > > Yadong Wang has updated the pull request incrementally with two additional commits since the last revision: > > - fix typo > - fix typo See: https://github.com/openjdk/jdk/pull/10075 ------------- PR: https://git.openjdk.org/jdk/pull/10056 From fjiang at openjdk.org Tue Aug 30 06:24:46 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 30 Aug 2022 06:24:46 GMT Subject: RFR: 8293065: Zero build failure on AArch64 and RISCV64 after JDK-8293007 Message-ID: [JDK-8293007](https://bugs.openjdk.org/browse/JDK-8293007) changes the `AARCH64_PORT_ONLY` macro into `AARCH64`, which is not an equivalent replacement. This patch also fixes the same zero build failure on RISCV64. Testing: - Linux AArch64 zero release build - Linux AArch64 server release build - Linux RISCV64 zero release build - Linux RISCV64 server release build ------------- Commit messages: - Fix riscv64/aarch64 zero build Changes: https://git.openjdk.org/jdk/pull/10075/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10075&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293065 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10075.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10075/head:pull/10075 PR: https://git.openjdk.org/jdk/pull/10075 From david.holmes at oracle.com Tue Aug 30 06:50:03 2022 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Aug 2022 16:50:03 +1000 Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v3] In-Reply-To: References: Message-ID: <0bb454e6-d207-6fb8-95c7-f3f002177065@oracle.com> I think this was an email-only comment ... On 30/08/2022 2:11 pm, Kim Barrett wrote: >> On Aug 29, 2022, at 8:55 PM, David Holmes wrote: >> >> On Mon, 29 Aug 2022 22:46:58 GMT, Kim Barrett wrote: >> >>>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >>>> >>>> Use PTR_FORMAT in AIX code >>> >>> src/hotspot/share/runtime/deoptimization.cpp line 1904: >>> >>>> 1902: >>>> 1903: // Log a message >>>> 1904: Events::log_deopt_message(current, "Uncommon trap: trap_request=" INT32_FORMAT_X_0 " fr.pc=" INTPTR_FORMAT " relative=" INTPTR_FORMAT, >>> >>> pre-existing: (first only) s/INTPTR_FORMAT/PTR_FORMAT/. >> >> I'm confused now about whether we use `p2i(x)` with `PTR_FORMAT` or `INTPTR_FORMAT`? `p2i` converts a pointer to an int so the resulting type should be `intptr_t` and so the format should be `INTPTR_FORMAT` - is that not so? > > I think PTR_FORMAT should always be used with the result of p2i ? we?re printing a pointer. So the p2i is just a hack to get around the fact gcc won't let us print a pointer directly using integer format specifiers? > I think using INTPTR_FORMAT with the result of p2i is a bug (though one that only affects code understanding, not execution). I think this is something we actively did a few years back when addressing missing p2i usage. But I was probably ther advocate of doing it this way. Cheers, David ----- > I think if we went through and fixed all of those misuses of INTPTR_FORMAT, some of the remaining > uses of it might be more appropriately using something else, like one of the INTX_FORMAT variants. > And I wonder what the residue from dealing with those might be - perhaps empty? > From eosterlund at openjdk.org Tue Aug 30 07:07:07 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 30 Aug 2022 07:07:07 GMT Subject: RFR: 8293065: Zero build failure on AArch64 and RISCV64 after JDK-8293007 In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 06:17:19 GMT, Feilong Jiang wrote: > [JDK-8293007](https://bugs.openjdk.org/browse/JDK-8293007) changes the `AARCH64_PORT_ONLY` macro into `AARCH64`, which is not an equivalent replacement. > This patch also fixes the same zero build failure on RISCV64. > > Testing: > > - Linux AArch64 zero release build > - Linux AArch64 server release build > - Linux RISCV64 zero release build > - Linux RISCV64 server release build Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/10075 From eosterlund at openjdk.org Tue Aug 30 07:16:50 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 30 Aug 2022 07:16:50 GMT Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 14:41:12 GMT, Yadong Wang wrote: >> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping. >> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre(). >> >> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth. >> >> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. >> >> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures. > > Yadong Wang has updated the pull request incrementally with two additional commits since the last revision: > > - fix typo > - fix typo Sorry for the late feedback but I'm not sure this looks right. src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2352: > 2350: __ lwu(t1, t1); > 2351: __ sw(t1, thread_epoch_addr); > 2352: __ membar(__ LoadLoad); Don't you need a FENCE.I instruction here? Similar to the AArch64 isb instruction. ------------- PR: https://git.openjdk.org/jdk/pull/10056 From fyang at openjdk.org Tue Aug 30 07:16:57 2022 From: fyang at openjdk.org (Fei Yang) Date: Tue, 30 Aug 2022 07:16:57 GMT Subject: RFR: 8293065: Zero build failure on AArch64 and RISCV64 after JDK-8293007 In-Reply-To: References: Message-ID: <_q13dSz2qhzZLVSfxuH8OPrmnbrFHvYKDHxTJe78IHs=.1c965e86-370d-4347-9881-f7b3f8bf1510@github.com> On Tue, 30 Aug 2022 06:17:19 GMT, Feilong Jiang wrote: > [JDK-8293007](https://bugs.openjdk.org/browse/JDK-8293007) changes the `AARCH64_PORT_ONLY` macro into `AARCH64`, which is not an equivalent replacement. > This patch also fixes the same zero build failure on RISCV64. > > Testing: > > - Linux AArch64 zero release build > - Linux AArch64 server release build > - Linux RISCV64 zero release build > - Linux RISCV64 server release build Looks fine to me. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10075 From aboldtch at openjdk.org Tue Aug 30 07:40:47 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 30 Aug 2022 07:40:47 GMT Subject: RFR: 8293035: Cleanup MacroAssembler::movoop code patching logic aarch64 riscv [v2] In-Reply-To: References: Message-ID: > Cleanup MacroAssembler::movoop logic with respect to code patching on aarch64 and riscv. > > Remove the `bool immediate` argument as it is only used with the value `true` in `void MacroAssembler::movoop(Register dst, jobject obj, bool immediate)` > > Make comments and logic more clear and easier to read. > > Testing: osx, linux aarch64 tier 1-3 Axel Boldt-Christmas 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 remote-tracking branch 'upstream/master' into JDK-8293035 - 8293035: Cleanup MacroAssembler::movoop code patching logic aarch64 riscv ------------- Changes: https://git.openjdk.org/jdk/pull/10065/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10065&range=01 Stats: 47 lines in 13 files changed: 12 ins; 14 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/10065.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10065/head:pull/10065 PR: https://git.openjdk.org/jdk/pull/10065 From yadongwang at openjdk.org Tue Aug 30 08:58:24 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Tue, 30 Aug 2022 08:58:24 GMT Subject: RFR: 8293065: Zero build failure on AArch64 and RISCV64 after JDK-8293007 In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 06:17:19 GMT, Feilong Jiang wrote: > [JDK-8293007](https://bugs.openjdk.org/browse/JDK-8293007) changes the `AARCH64_PORT_ONLY` macro into `AARCH64`, which is not an equivalent replacement. > This patch also fixes the same zero build failure on RISCV64. > > Testing: > > - Linux AArch64 zero release build > - Linux AArch64 server release build > - Linux RISCV64 zero release build > - Linux RISCV64 server release build lgtm(not a reviewer) ------------- Marked as reviewed by yadongwang (Author). PR: https://git.openjdk.org/jdk/pull/10075 From duke at openjdk.org Tue Aug 30 09:08:24 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 30 Aug 2022 09:08:24 GMT Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls In-Reply-To: References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com> Message-ID: On Wed, 17 Aug 2022 12:09:05 GMT, Evgeny Astigeevich wrote: >> Hi Andrew(@theRealAph), >> Your comments are usually highly useful and help to identify missed issues. >> Do you have any of them? >> Thanks, >> Evgeny > >> Hi @eastig , I'd like to ask you how to get the experiment results, aka. `Saved bytes`, `Nmethods with shared stubs`,`Final # of nmethods`. Thank you! > > You can get `Final # of nmethods` with `-XX:+PrintCodeCache`. > To get `Saved bytes`, `Nmethods with shared stubs` you need to instrument `emit_shared_stubs_to_interp` to count shared stubs and nmethods sharing them. > Hi @eastig , > I would like to recurring your experimental data and I would be very grateful if you could provide a small patch to help me get the result of `Saved bytes` and `Nmethods with shared stubs`. > Thank you! diff --git a/src/hotspot/share/asm/codeBuffer.inline.hpp b/src/hotspot/share/asm/codeBuffer.inline.hpp index 045cff13f25..9af26730cbd 100644 --- a/src/hotspot/share/asm/codeBuffer.inline.hpp +++ b/src/hotspot/share/asm/codeBuffer.inline.hpp @@ -45,6 +45,7 @@ bool emit_shared_stubs_to_interp(CodeBuffer* cb, SharedStubToInterpRequests* sha }; shared_stub_to_interp_requests->sort(by_shared_method); MacroAssembler masm(cb); + bool has_shared = false; for (int i = 0; i < shared_stub_to_interp_requests->length();) { address stub = masm.start_a_stub(CompiledStaticCall::to_interp_stub_size()); if (stub == NULL) { @@ -53,13 +54,22 @@ bool emit_shared_stubs_to_interp(CodeBuffer* cb, SharedStubToInterpRequests* sha } ciMethod* method = shared_stub_to_interp_requests->at(i).shared_method(); + int shared = 0; do { address caller_pc = cb->insts_begin() + shared_stub_to_interp_requests->at(i).call_offset(); masm.relocate(static_stub_Relocation::spec(caller_pc), relocate_format); ++i; + ++shared; } while (i < shared_stub_to_interp_requests->length() && shared_stub_to_interp_requests->at(i).shared_method() == method); masm.emit_static_call_stub(); masm.end_a_stub(); + if (UseNewCode && shared > 1) { + has_shared = true; + tty->print_cr("Saved: %d", (shared - 1) * CompiledStaticCall::to_interp_stub_size()); + } + } + if (has_shared) { + tty->print_cr("nm_has_shared"); } return true; } You will need to use `-XX:+UseNewCode` in your runs. `grep nm_has_shared run.log | wc -l` is a number of nmethods having a shared stub. `grep Saved: run.log | awk '{print $2}' | grep -o '[0-9]*' | paste -s -d+ - | bc` prints a number of saved bytes. ------------- PR: https://git.openjdk.org/jdk/pull/8816 From yadongwang at openjdk.org Tue Aug 30 09:10:13 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Tue, 30 Aug 2022 09:10:13 GMT Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2] In-Reply-To: References: Message-ID: <9vNWr4kJDCJeWaXcxGHpgOUH-VFNqsZ0WN2UcJTJavY=.4081e45d-da6e-41d8-8854-8868321791cb@github.com> On Tue, 30 Aug 2022 07:12:45 GMT, Erik ?sterlund wrote: >> Yadong Wang has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix typo >> - fix typo > > src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2352: > >> 2350: __ lwu(t1, t1); >> 2351: __ sw(t1, thread_epoch_addr); >> 2352: __ membar(__ LoadLoad); > > Don't you need a FENCE.I instruction here? Similar to the AArch64 isb instruction. We don't need a fence.i here in the riscv port , see our discussion in https://mail.openjdk.org/pipermail/riscv-port- dev/2022-July/000572.html. In the riscv world, fence.i in user-space cannot guarante the read hart see the modified code because threads may migrate to other processor core after fence.i. Instead, we called icache_flush() after the write hart modified code, which synchronized all harts to flush icache by IPI in kernel mode. So the read hart do not need a fence.i. ------------- PR: https://git.openjdk.org/jdk/pull/10056 From jpai at openjdk.org Tue Aug 30 09:16:16 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 30 Aug 2022 09:16:16 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5] In-Reply-To: References: Message-ID: <8NfRtLx-sAEoJqvDeVwo9SFSASKzMN6w7ul9yw-7C98=.d41ee1ea-efa1-498f-9b5a-ca0acf738921@github.com> On Tue, 23 Aug 2022 11:22:55 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 7. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Update configure to check for jtreg 7 or later > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Revert junit.java > > Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Update to new JUnit JAR file > > With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2"). > This change updates the hard-coded library tag value to the new JUnit JAR file. > Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316, > in order to unblock the "Update to use jtreg 7" PR 9393: > https://github.com/openjdk/jdk/pull/9393 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - ... and 3 more: https://git.openjdk.org/jdk/compare/cf006774...bbf53448 Hello Christian, is it intentional that in some file the minimum required jtreg version is represented as `7` (`lib-tests.m4`) and in some other files as `7+1` (GitHub actions config file, then the TEST.ROOT files)? ------------- PR: https://git.openjdk.org/jdk/pull/9393 From fjiang at openjdk.org Tue Aug 30 09:19:28 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 30 Aug 2022 09:19:28 GMT Subject: RFR: 8292575: riscv: Represent Registers as values [v4] In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 03:41:50 GMT, Fei Yang wrote: >> Feilong Jiang 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' of https://github.com/openjdk/jdk into riscv-register-rep >> - remove duplicate code >> - Merge branch 'master' of https://github.com/openjdk/jdk into riscv-register-rep >> - Represent Registers as values > > Updated changes look good. Thanks. @RealFYang @yhzhu20 @yadongw -- Thanks for the review! ------------- PR: https://git.openjdk.org/jdk/pull/9936 From duke at openjdk.org Tue Aug 30 09:27:07 2022 From: duke at openjdk.org (Dingli Zhang) Date: Tue, 30 Aug 2022 09:27:07 GMT Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls In-Reply-To: References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com> Message-ID: On Tue, 30 Aug 2022 09:04:21 GMT, Evgeny Astigeevich wrote: > > Hi @eastig , > > I would like to recurring your experimental data and I would be very grateful if you could provide a small patch to help me get the result of `Saved bytes` and `Nmethods with shared stubs`. > > Thank you! > > ``` > diff --git a/src/hotspot/share/asm/codeBuffer.inline.hpp b/src/hotspot/share/asm/codeBuffer.inline.hpp > index 045cff13f25..9af26730cbd 100644 > --- a/src/hotspot/share/asm/codeBuffer.inline.hpp > +++ b/src/hotspot/share/asm/codeBuffer.inline.hpp > @@ -45,6 +45,7 @@ bool emit_shared_stubs_to_interp(CodeBuffer* cb, SharedStubToInterpRequests* sha > }; > shared_stub_to_interp_requests->sort(by_shared_method); > MacroAssembler masm(cb); > + bool has_shared = false; > for (int i = 0; i < shared_stub_to_interp_requests->length();) { > address stub = masm.start_a_stub(CompiledStaticCall::to_interp_stub_size()); > if (stub == NULL) { > @@ -53,13 +54,22 @@ bool emit_shared_stubs_to_interp(CodeBuffer* cb, SharedStubToInterpRequests* sha > } > > ciMethod* method = shared_stub_to_interp_requests->at(i).shared_method(); > + int shared = 0; > do { > address caller_pc = cb->insts_begin() + shared_stub_to_interp_requests->at(i).call_offset(); > masm.relocate(static_stub_Relocation::spec(caller_pc), relocate_format); > ++i; > + ++shared; > } while (i < shared_stub_to_interp_requests->length() && shared_stub_to_interp_requests->at(i).shared_method() == method); > masm.emit_static_call_stub(); > masm.end_a_stub(); > + if (UseNewCode && shared > 1) { > + has_shared = true; > + tty->print_cr("Saved: %d", (shared - 1) * CompiledStaticCall::to_interp_stub_size()); > + } > + } > + if (has_shared) { > + tty->print_cr("nm_has_shared"); > } > return true; > } > ``` > > You will need to use `-XX:+UseNewCode` in your runs. `grep nm_has_shared run.log | wc -l` is a number of nmethods having a shared stub. `grep Saved: run.log | awk '{print $2}' | grep -o '[0-9]*' | paste -s -d+ - | bc` prints a number of saved bytes. Thanks a lot, eastig! ------------- PR: https://git.openjdk.org/jdk/pull/8816 From fjiang at openjdk.org Tue Aug 30 09:29:17 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 30 Aug 2022 09:29:17 GMT Subject: Integrated: 8292575: riscv: Represent Registers as values In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 07:30:14 GMT, Feilong Jiang wrote: > Follow up [JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153) and [JDK-8292203](https://bugs.openjdk.org/browse/JDK-8292203), migrate away from pointer-based representation of Register values. > > It improves compile-time checking by forbidding implicit conversions between integrals and pointers. > > Testing: > - hotspot/jdk tier1 on unmatched board > - hotspot/jdk tier1 on qemu This pull request has now been integrated. Changeset: 21a73695 Author: Feilong Jiang Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/21a736954f4e6a9b41b382908d1875518c4caccb Stats: 509 lines in 14 files changed: 136 ins; 76 del; 297 mod 8292575: riscv: Represent Registers as values Reviewed-by: yzhu, yadongwang, fyang ------------- PR: https://git.openjdk.org/jdk/pull/9936 From cstein at openjdk.org Tue Aug 30 09:33:05 2022 From: cstein at openjdk.org (Christian Stein) Date: Tue, 30 Aug 2022 09:33:05 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5] In-Reply-To: <8NfRtLx-sAEoJqvDeVwo9SFSASKzMN6w7ul9yw-7C98=.d41ee1ea-efa1-498f-9b5a-ca0acf738921@github.com> References: <8NfRtLx-sAEoJqvDeVwo9SFSASKzMN6w7ul9yw-7C98=.d41ee1ea-efa1-498f-9b5a-ca0acf738921@github.com> Message-ID: <6A9Z9oXjfXGmi9_LWIF_TMtJtS483A98QA0rJPuzus0=.ab5a3a72-7877-4bbf-8c39-5663476ac5e1@github.com> On Tue, 30 Aug 2022 09:14:12 GMT, Jaikiran Pai wrote: > Hello Christian, is it intentional that in some file the minimum required jtreg version is represented as `7` (`lib-tests.m4`) and in some other files as `7+1` (GitHub actions config file, then the TEST.ROOT files)? Yes. Some systems require the exact version tag `7+1` others only the short version string `7`. ------------- PR: https://git.openjdk.org/jdk/pull/9393 From jpai at openjdk.org Tue Aug 30 09:36:15 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 30 Aug 2022 09:36:15 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v5] In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 11:22:55 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 7. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Update configure to check for jtreg 7 or later > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Revert junit.java > > Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Update to new JUnit JAR file > > With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2"). > This change updates the hard-coded library tag value to the new JUnit JAR file. > Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316, > in order to unblock the "Update to use jtreg 7" PR 9393: > https://github.com/openjdk/jdk/pull/9393 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - ... and 3 more: https://git.openjdk.org/jdk/compare/cf006774...bbf53448 Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9393 From fyang at openjdk.org Tue Aug 30 11:17:53 2022 From: fyang at openjdk.org (Fei Yang) Date: Tue, 30 Aug 2022 11:17:53 GMT Subject: RFR: 8293050: RISC-V: Remove redundant non-null assertions about macro-assembler Message-ID: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> There are some non-null assertions about macro-assembler in riscv-specific code. Most of them are there to make some internal code-check tools happy. We should remove those redundant assertions to make the code clean. Tested with tier1 hotspot on linux-riscv64 unmatched. ------------- Commit messages: - 8293050: RISC-V: Remove redundant non-null assertions about macro-assembler Changes: https://git.openjdk.org/jdk/pull/10079/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10079&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293050 Stats: 54 lines in 9 files changed: 0 ins; 47 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10079.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10079/head:pull/10079 PR: https://git.openjdk.org/jdk/pull/10079 From fjiang at openjdk.org Tue Aug 30 11:39:06 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 30 Aug 2022 11:39:06 GMT Subject: RFR: 8293050: RISC-V: Remove redundant non-null assertions about macro-assembler In-Reply-To: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> References: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> Message-ID: On Tue, 30 Aug 2022 11:12:30 GMT, Fei Yang wrote: > There are some non-null assertions about macro-assembler in riscv-specific code. Most of them are there to make some internal code-check tools happy. We should remove those redundant assertions to make the code clean. > > Tested with tier1 hotspot on linux-riscv64 unmatched. Marked as reviewed by fjiang (Author). Nice clean up! LGTM. ------------- PR: https://git.openjdk.org/jdk/pull/10079 From alanb at openjdk.org Tue Aug 30 11:44:11 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Aug 2022 11:44:11 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals [v2] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 21:33:13 GMT, Serguei Spitsyn wrote: >> If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. >> >> The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. >> It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. >> >> The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. >> >> The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. >> >> The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. >> >> The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove unneeded commented lines in test Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10051 From jbhateja at openjdk.org Tue Aug 30 12:28:07 2022 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 30 Aug 2022 12:28:07 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v4] In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 05:18:35 GMT, Tobias Hartmann wrote: > Does this fix [JDK-8293039](https://bugs.openjdk.org/browse/JDK-8293039) as well? Hi @TobiHartmann , yes it should. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From stefank at openjdk.org Tue Aug 30 12:58:38 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 30 Aug 2022 12:58:38 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: References: Message-ID: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> > Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. > > This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. > > We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. > > I'd like to suggest that we use a convention to specify what we want. This is the current proposal: > > // Guide to the suffixes used in the format specifiers for integers: > // - print the decimal value: 745565 > // _X - print as hexadecimal, without leading 0s: 0x12345 > // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 > // _H - print as hexadecimal, without 0x prefix > // _W(w) - prints w sized string with the given value right > // adjusted. Use -w to print left adjusted. > // > // Note that the PTR format specifiers print using 0x with leading zeros, > // just like the _X_0 version for integers. > > > The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Move INTPTR_FORMAT_H_W to Shenandoah ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10042/files - new: https://git.openjdk.org/jdk/pull/10042/files/0f3bdd26..53d40ef5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=02-03 Stats: 9 lines in 2 files changed: 5 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10042.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10042/head:pull/10042 PR: https://git.openjdk.org/jdk/pull/10042 From stefank at openjdk.org Tue Aug 30 12:58:39 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 30 Aug 2022 12:58:39 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v3] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 23:59:26 GMT, Kim Barrett wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Use PTR_FORMAT in AIX code > > src/hotspot/share/utilities/globalDefinitions.hpp line 169: > >> 167: #define PTR_FORMAT "0x%08" PRIxPTR >> 168: #endif // _LP64 >> 169: #define INTPTR_FORMAT_H_W(width) "%" #width PRIxPTR > > The naming of INTPTR_FORMAT_H_W is inconsistent with INTPTR_FORMAT. It seems only used in one area of Shenandoah code, where it seems like they should be using PTR_FORMAT, except they are trying to output fewer leading zeros. I'm somewhat inclined to say this doesn't belong in globalDefinitions.hpp at all; if they have specialized printing desirements they can define whatever they want themselves. I've moved this to Shenandoah now. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From stefank at openjdk.org Tue Aug 30 12:58:38 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 30 Aug 2022 12:58:38 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v2] In-Reply-To: References: Message-ID: <63g1KYoa_9-G1tGN8wwonQnKO8U2n68izCeEZ67aFRA=.ffe18b13-a702-462c-9626-58b84805719c@github.com> On Mon, 29 Aug 2022 12:15:17 GMT, David Holmes wrote: >>> (And yes we have to cast the ptrs to int using p2i but that is just because of compiler limitations/issues ... which raises the recurring old question of "have we finally reached a point where we can use %p cross-platform?") >> >> One motivation for using PTR_FORMAT instead of %p, is to get consistent output on all platforms. I ran the following on different OSes: >> >> tty->print_cr("%p " PTR_FORMAT, (void*)0x12345678, (uintptr_t)0x12345678); >> >> And the result is: >> >> Linux: 0x12345678 0x0000000012345678 >> macOS: 0x12345678 0x0000000012345678 >> Win: 0x0000000012345678 0x0000000012345678 >> >> >> I also tested getting zero padding on Linux, but the compiler informs me that that's not allowed: `error: '0' flag used with '%p' gnu_printf format"`. > >> One motivation for using PTR_FORMAT instead of %p, is to get consistent output on all platforms. > > Yes that has always been the problem, but I wondered whether this issue was perhaps finally resolved. Based on your results we seem closer - they all have leading 0x - but they still differ in leading zeroes. I have a recollection now that someone tried using %p fairly recently (ie last 12-24 months) and also discovered this. Kind of sad that something so conceptually simple has proven to be so difficult to get right. @dholmes-ora Do you have any actionable items that you want me to do for this PR? ------------- PR: https://git.openjdk.org/jdk/pull/10042 From thartmann at openjdk.org Tue Aug 30 13:04:52 2022 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 30 Aug 2022 13:04:52 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v4] In-Reply-To: References: Message-ID: On Sat, 27 Aug 2022 16:58:48 GMT, Jatin Bhateja wrote: >> Hi, >> >> This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. >> A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8291649: Incorporating further refinements from Kim. Thanks for verifying, I closed it as duplicate. ------------- PR: https://git.openjdk.org/jdk/pull/9987 From coleenp at openjdk.org Tue Aug 30 13:36:53 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 Aug 2022 13:36:53 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> Message-ID: On Tue, 30 Aug 2022 12:58:38 GMT, Stefan Karlsson wrote: >> Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. >> >> This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. >> >> We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. >> >> I'd like to suggest that we use a convention to specify what we want. This is the current proposal: >> >> // Guide to the suffixes used in the format specifiers for integers: >> // - print the decimal value: 745565 >> // _X - print as hexadecimal, without leading 0s: 0x12345 >> // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >> // _H - print as hexadecimal, without 0x prefix >> // _W(w) - prints w sized string with the given value right >> // adjusted. Use -w to print left adjusted. >> // >> // Note that the PTR format specifiers print using 0x with leading zeros, >> // just like the _X_0 version for integers. >> >> >> The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Move INTPTR_FORMAT_H_W to Shenandoah src/hotspot/share/utilities/globalDefinitions.hpp line 110: > 108: // Format 16-bit quantities. > 109: #define INT16_FORMAT_X_0 "0x%04" PRIx16 > 110: #define UINT16_FORMAT_X_0 "0x%04" PRIx16 I'm confused. What's the trailing 0 ? is it to print the "0x" part of the hex format? And why wouldn't you want that? ------------- PR: https://git.openjdk.org/jdk/pull/10042 From stefank at openjdk.org Tue Aug 30 14:22:14 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 30 Aug 2022 14:22:14 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> Message-ID: On Tue, 30 Aug 2022 13:33:18 GMT, Coleen Phillimore wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Move INTPTR_FORMAT_H_W to Shenandoah > > src/hotspot/share/utilities/globalDefinitions.hpp line 110: > >> 108: // Format 16-bit quantities. >> 109: #define INT16_FORMAT_X_0 "0x%04" PRIx16 >> 110: #define UINT16_FORMAT_X_0 "0x%04" PRIx16 > > I'm confused. What's the trailing 0 ? is it to print the "0x" part of the hex format? And why wouldn't you want that? I tried to describe it above: // _X - print as hexadecimal, without leading 0s: 0x12345 // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 It's about padding with 0s. So, that you get 0x00012345 instead of 0x12345. Do you have a suggestion on how to write that comment any clearer? ------------- PR: https://git.openjdk.org/jdk/pull/10042 From jrose at openjdk.org Tue Aug 30 15:18:27 2022 From: jrose at openjdk.org (John R Rose) Date: Tue, 30 Aug 2022 15:18:27 GMT Subject: RFR: 8291649: multiple tests failing with -Xcomp after JDK-8290034 [v4] In-Reply-To: References: Message-ID: On Sat, 27 Aug 2022 16:58:48 GMT, Jatin Bhateja wrote: >> Hi, >> >> This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. >> A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8291649: Incorporating further refinements from Kim. Marked as reviewed by jrose (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9987 From duke at openjdk.org Tue Aug 30 15:24:25 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Aug 2022 15:24:25 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: References: <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com> Message-ID: On Mon, 29 Aug 2022 16:09:05 GMT, Erik ?sterlund wrote: > The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not. @fisk are you suggesting that changing the Access API from `set_parent_raw` to `set_parent_access` is the right approach? This introduces gc policy specific code which does not look clean. It appears that the combination of `requires_barriers()` and `do_barriers()` API is suppose to encapsulate the gc policy specific requirements. `requires_barriers()` would handle any gc specific requirement for using barriers and `do_barriers()` would then take the necessary action. This makes sense as it keeps the code clean. wdyt? ------------- PR: https://git.openjdk.org/jdk/pull/9982 From eosterlund at openjdk.org Tue Aug 30 15:46:07 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 30 Aug 2022 15:46:07 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: References: <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com> Message-ID: On Tue, 30 Aug 2022 15:20:48 GMT, Ashutosh Mehra wrote: > > The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not. > > @fisk are you suggesting that changing the Access API from `set_parent_raw` to `set_parent_access` is the right approach? This introduces gc policy specific code which does not look clean. It appears that the combination of `requires_barriers()` and `do_barriers()` API is suppose to encapsulate the gc policy specific requirements. `requires_barriers()` would handle any gc specific requirement for using barriers and `do_barriers()` would then take the necessary action. This makes sense as it keeps the code clean. wdyt? That is precisely what I am suggesting. The situation is the opposite from what you think. The Access API *is* the public interface to the GC, that will do the right thing for all GCs, while the requires_barriers and do_barriers stuff is less general, as I just discussed. ------------- PR: https://git.openjdk.org/jdk/pull/9982 From duke at openjdk.org Tue Aug 30 16:02:00 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Aug 2022 16:02:00 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: References: <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com> Message-ID: On Tue, 30 Aug 2022 15:42:31 GMT, Erik ?sterlund wrote: >>> The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not. >> >> @fisk are you suggesting that changing the Access API from `set_parent_raw` to `set_parent_access` is the right approach? This introduces gc policy specific code which does not look clean. >> It appears that the combination of `requires_barriers()` and `do_barriers()` API is suppose to encapsulate the gc policy specific requirements. `requires_barriers()` would handle any gc specific requirement for using barriers and `do_barriers()` would then take the necessary action. This makes sense as it keeps the code clean. wdyt? > >> > The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not. >> >> @fisk are you suggesting that changing the Access API from `set_parent_raw` to `set_parent_access` is the right approach? This introduces gc policy specific code which does not look clean. It appears that the combination of `requires_barriers()` and `do_barriers()` API is suppose to encapsulate the gc policy specific requirements. `requires_barriers()` would handle any gc specific requirement for using barriers and `do_barriers()` would then take the necessary action. This makes sense as it keeps the code clean. wdyt? > > That is precisely what I am suggesting. The situation is the opposite from what you think. The Access API *is* the public interface to the GC, that will do the right thing for all GCs, while the requires_barriers and do_barriers stuff is less general, as I just discussed. @fisk you are right, I see now that `set_parent_access` is a no-op for satb barriers. So we can just change `set_parent_raw` to `set_parent_access` for all gc policies, right? btw `set_parent_access` is missing in the mainline, so I would have to add this API (and the corresponding API oop::obj_field_put_access) as well. Does that make sense? ------------- PR: https://git.openjdk.org/jdk/pull/9982 From eosterlund at openjdk.org Tue Aug 30 16:02:00 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 30 Aug 2022 16:02:00 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: References: <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com> Message-ID: <7ikOdW5iF-kptYo_k02QoZOPXVUeU1OVqsDk0r7FF98=.daca7ba6-3711-4f02-bf9e-755705a029a8@github.com> On Tue, 30 Aug 2022 15:42:31 GMT, Erik ?sterlund wrote: >>> The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not. >> >> @fisk are you suggesting that changing the Access API from `set_parent_raw` to `set_parent_access` is the right approach? This introduces gc policy specific code which does not look clean. >> It appears that the combination of `requires_barriers()` and `do_barriers()` API is suppose to encapsulate the gc policy specific requirements. `requires_barriers()` would handle any gc specific requirement for using barriers and `do_barriers()` would then take the necessary action. This makes sense as it keeps the code clean. wdyt? > >> > The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not. >> >> @fisk are you suggesting that changing the Access API from `set_parent_raw` to `set_parent_access` is the right approach? This introduces gc policy specific code which does not look clean. It appears that the combination of `requires_barriers()` and `do_barriers()` API is suppose to encapsulate the gc policy specific requirements. `requires_barriers()` would handle any gc specific requirement for using barriers and `do_barriers()` would then take the necessary action. This makes sense as it keeps the code clean. wdyt? > > That is precisely what I am suggesting. The situation is the opposite from what you think. The Access API *is* the public interface to the GC, that will do the right thing for all GCs, while the requires_barriers and do_barriers stuff is less general, as I just discussed. > @fisk you are right, I see now that `set_parent_access` is a no-op for satb barriers. So we can just change `set_parent_raw` to `set_parent_access` for all gc policies, right? > > btw `set_parent_access` is missing in the mainline, so I would have to add this API (and the corresponding API oop::obj_field_put_access) as well. Does that make sense? That sounds great! :) ------------- PR: https://git.openjdk.org/jdk/pull/9982 From coleenp at openjdk.org Tue Aug 30 16:03:08 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 Aug 2022 16:03:08 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> Message-ID: On Tue, 30 Aug 2022 14:18:37 GMT, Stefan Karlsson wrote: >> src/hotspot/share/utilities/globalDefinitions.hpp line 110: >> >>> 108: // Format 16-bit quantities. >>> 109: #define INT16_FORMAT_X_0 "0x%04" PRIx16 >>> 110: #define UINT16_FORMAT_X_0 "0x%04" PRIx16 >> >> I'm confused. What's the trailing 0 ? is it to print the "0x" part of the hex format? And why wouldn't you want that? > > I tried to describe it above: > > // _X - print as hexadecimal, without leading 0s: 0x12345 > // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 > > > It's about padding with 0s. So, that you get 0x00012345 instead of 0x12345. Do you have a suggestion on how to write that comment any clearer? I see that now. I wandered into the diffs to quickly see what this is about and saw this without the comment and it looked strange. Maybe _0X would also look strange, or even _0_X. I assume these alternatives have been discussed and discarded. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From kvn at openjdk.org Tue Aug 30 16:44:14 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 30 Aug 2022 16:44:14 GMT Subject: RFR: 8293065: Zero build failure on AArch64 and RISCV64 after JDK-8293007 In-Reply-To: References: Message-ID: <2DkQJX-PmGzPvTg4jIuwRlLFst8Ipn-I-9WIc9Myudk=.e123b737-c3ee-4d45-a4cb-98db3148514f@github.com> On Tue, 30 Aug 2022 06:17:19 GMT, Feilong Jiang wrote: > [JDK-8293007](https://bugs.openjdk.org/browse/JDK-8293007) changes the `AARCH64_PORT_ONLY` macro into `AARCH64`, which is not an equivalent replacement. > This patch also fixes the same zero build failure on RISCV64. > > Testing: > > - Linux AArch64 zero release build > - Linux AArch64 server release build > - Linux RISCV64 zero release build > - Linux RISCV64 server release build Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10075 From sspitsyn at openjdk.org Tue Aug 30 16:47:14 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 30 Aug 2022 16:47:14 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals [v2] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 21:33:13 GMT, Serguei Spitsyn wrote: >> If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. >> >> The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. >> It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. >> >> The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. >> >> The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. >> >> The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. >> >> The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove unneeded commented lines in test Thank you for review, Alan! ------------- PR: https://git.openjdk.org/jdk/pull/10051 From vlivanov at openjdk.org Tue Aug 30 17:12:01 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 30 Aug 2022 17:12:01 GMT Subject: RFR: 8293036: x86_64: Move Continuation-related stub methods to MacroAssembler In-Reply-To: <1M2F-T10O-tziQRrEx1e_vFWu98boRiqbjg7D0XPEoc=.cbe3298a-bc24-44f3-ae99-76e9bbc69f59@github.com> References: <1M2F-T10O-tziQRrEx1e_vFWu98boRiqbjg7D0XPEoc=.cbe3298a-bc24-44f3-ae99-76e9bbc69f59@github.com> Message-ID: On Mon, 29 Aug 2022 17:17:22 GMT, Vladimir Ivanov wrote: > Move Continuation-related methods from `stubGenerator_x86_64.cpp` under `MacroAssembler`. > > Testing: hs-tier1 - hs-tier2 Thanks for the review, Vladimir. ------------- PR: https://git.openjdk.org/jdk/pull/10066 From vlivanov at openjdk.org Tue Aug 30 17:12:03 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 30 Aug 2022 17:12:03 GMT Subject: Integrated: 8293036: x86_64: Move Continuation-related stub methods to MacroAssembler In-Reply-To: <1M2F-T10O-tziQRrEx1e_vFWu98boRiqbjg7D0XPEoc=.cbe3298a-bc24-44f3-ae99-76e9bbc69f59@github.com> References: <1M2F-T10O-tziQRrEx1e_vFWu98boRiqbjg7D0XPEoc=.cbe3298a-bc24-44f3-ae99-76e9bbc69f59@github.com> Message-ID: On Mon, 29 Aug 2022 17:17:22 GMT, Vladimir Ivanov wrote: > Move Continuation-related methods from `stubGenerator_x86_64.cpp` under `MacroAssembler`. > > Testing: hs-tier1 - hs-tier2 This pull request has now been integrated. Changeset: f3ebb420 Author: Vladimir Ivanov URL: https://git.openjdk.org/jdk/commit/f3ebb420b7809f2b96feab3426d4ef40a610df7b Stats: 238 lines in 4 files changed: 126 ins; 105 del; 7 mod 8293036: x86_64: Move Continuation-related stub methods to MacroAssembler Reviewed-by: dlong, kvn ------------- PR: https://git.openjdk.org/jdk/pull/10066 From shade at openjdk.org Tue Aug 30 17:25:12 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 30 Aug 2022 17:25:12 GMT Subject: RFR: 8292878: x86: Make scratch register usage explicit in assembler code [v4] In-Reply-To: <_sbLJhUd3BdQ3Zr9djztIvwhyBa8i-YD7nPyr54Le_g=.3fa77f28-b558-4f54-a987-579e5d8564a3@github.com> References: <75euD5SuLprNP7TWtaG57I-ePW0vkSh77mo2qEarevI=.f012660b-febc-409c-99fd-731b482fb31b@github.com> <_sbLJhUd3BdQ3Zr9djztIvwhyBa8i-YD7nPyr54Le_g=.3fa77f28-b558-4f54-a987-579e5d8564a3@github.com> Message-ID: On Mon, 29 Aug 2022 17:08:39 GMT, Vladimir Ivanov wrote: > @shipilev Aleksey, do you plan to look into x86_32-specific changes? Otherwise, I'll integrate the patch. Missed this comment, sorry. Are you looking for a similar change on x86_32-specific code? I believe x86_32 code does not use scratch registers (they are `#define`-d to `noreg`), so there seem to be nothing to do. I see GHA infra barfed up on x86_32 tests, I'll run some tests locally. ------------- PR: https://git.openjdk.org/jdk/pull/10003 From stefank at openjdk.org Tue Aug 30 17:25:14 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 30 Aug 2022 17:25:14 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> Message-ID: On Tue, 30 Aug 2022 15:59:19 GMT, Coleen Phillimore wrote: >> I tried to describe it above: >> >> // _X - print as hexadecimal, without leading 0s: 0x12345 >> // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >> >> >> It's about padding with 0s. So, that you get 0x00012345 instead of 0x12345. Do you have a suggestion on how to write that comment any clearer? > > I see that now. I wandered into the diffs to quickly see what this is about and saw this without the comment and it looked strange. Maybe _0X would also look strange, or even _0_X. I assume these alternatives have been discussed and discarded. They have not been discussed. I looked for a pragmatic solution to the problem that parts of the code have different formatting requirements, and then selected one naming convention that I liked. This can still be changed if we can agree on a another / better naming convention. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From vlivanov at openjdk.org Tue Aug 30 17:44:06 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 30 Aug 2022 17:44:06 GMT Subject: RFR: 8292878: x86: Make scratch register usage explicit in assembler code [v4] In-Reply-To: <75euD5SuLprNP7TWtaG57I-ePW0vkSh77mo2qEarevI=.f012660b-febc-409c-99fd-731b482fb31b@github.com> References: <75euD5SuLprNP7TWtaG57I-ePW0vkSh77mo2qEarevI=.f012660b-febc-409c-99fd-731b482fb31b@github.com> Message-ID: On Thu, 25 Aug 2022 22:19:14 GMT, Vladimir Ivanov wrote: >> Improve MacroAssembler API and make scratch register usages explicit at use sites. >> >> Different parts of JVM have different assumptions about scratch registers and >> implicit assumptions in MacroAssembler makes it harder to reason about the >> correctness of generated code. >> >> Most of scratch register usages relate to `AddressLiteral` on x86_64. In such case the argument is turned into a default one (with `noreg` as a default) and implementation asserts that scratch register should be provided when the address is not guaranteed to be always reachable. >> >> Otherwise, scratch register argument is required to be explicitly provided. >> >> The only case left (mostly) intact is `call(AddressLiteral)`, but I switched it from `rscratch` (`r10`) to `rax`. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 (w/ -XX:+-ForceUnreachable) >> - [x] x86_32 build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > x86_32 Thanks. Just wanted to hear from you since it affects x86_32 in a non-trivial way. ------------- PR: https://git.openjdk.org/jdk/pull/10003 From iklam at openjdk.org Tue Aug 30 18:17:12 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 30 Aug 2022 18:17:12 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Mon, 29 Aug 2022 12:10:48 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/protectionDomainCache.cpp line 43: >> >>> 41: >>> 42: unsigned int ProtectionDomainCacheTable::compute_hash(const WeakHandle& protection_domain) { >>> 43: return (unsigned int)(protection_domain.resolve()->identity_hash()); >> >> And if it is a `WeakHandle` can't `resolve` now return NULL? > > compute_hash() is always called on a live WeakHandle so will never return null. I think you should add an assert that the `protection_domain.resolve()` never returns null, with a comment explaining why. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From sspitsyn at openjdk.org Tue Aug 30 18:32:30 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 30 Aug 2022 18:32:30 GMT Subject: Integrated: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 20:13:28 GMT, Serguei Spitsyn wrote: > If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. > > The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. > It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. > > The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. > > The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. > > The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. > > The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. This pull request has now been integrated. Changeset: f5ebbf32 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/f5ebbf3225fc10367ef4e2b4ec62e9077565e6aa Stats: 39 lines in 6 files changed: 24 ins; 2 del; 13 mod 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals Reviewed-by: cjplummer, alanb ------------- PR: https://git.openjdk.org/jdk/pull/10051 From shade at openjdk.org Tue Aug 30 18:41:14 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 30 Aug 2022 18:41:14 GMT Subject: RFR: 8292878: x86: Make scratch register usage explicit in assembler code [v4] In-Reply-To: <75euD5SuLprNP7TWtaG57I-ePW0vkSh77mo2qEarevI=.f012660b-febc-409c-99fd-731b482fb31b@github.com> References: <75euD5SuLprNP7TWtaG57I-ePW0vkSh77mo2qEarevI=.f012660b-febc-409c-99fd-731b482fb31b@github.com> Message-ID: <1s6dFBWVFNx42Rvfok9jvhSbD3Ob9ckReov3C6bdFkQ=.cbc8d839-c27a-46af-84d6-7e25e8e351ed@github.com> On Thu, 25 Aug 2022 22:19:14 GMT, Vladimir Ivanov wrote: >> Improve MacroAssembler API and make scratch register usages explicit at use sites. >> >> Different parts of JVM have different assumptions about scratch registers and >> implicit assumptions in MacroAssembler makes it harder to reason about the >> correctness of generated code. >> >> Most of scratch register usages relate to `AddressLiteral` on x86_64. In such case the argument is turned into a default one (with `noreg` as a default) and implementation asserts that scratch register should be provided when the address is not guaranteed to be always reachable. >> >> Otherwise, scratch register argument is required to be explicitly provided. >> >> The only case left (mostly) intact is `call(AddressLiteral)`, but I switched it from `rscratch` (`r10`) to `rax`. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 (w/ -XX:+-ForceUnreachable) >> - [x] x86_32 build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > x86_32 I think we are fine. `tier1` and `tier2` pass on x86_32. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10003 From vlivanov at openjdk.org Tue Aug 30 18:46:17 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 30 Aug 2022 18:46:17 GMT Subject: RFR: 8292878: x86: Make scratch register usage explicit in assembler code [v4] In-Reply-To: <75euD5SuLprNP7TWtaG57I-ePW0vkSh77mo2qEarevI=.f012660b-febc-409c-99fd-731b482fb31b@github.com> References: <75euD5SuLprNP7TWtaG57I-ePW0vkSh77mo2qEarevI=.f012660b-febc-409c-99fd-731b482fb31b@github.com> Message-ID: On Thu, 25 Aug 2022 22:19:14 GMT, Vladimir Ivanov wrote: >> Improve MacroAssembler API and make scratch register usages explicit at use sites. >> >> Different parts of JVM have different assumptions about scratch registers and >> implicit assumptions in MacroAssembler makes it harder to reason about the >> correctness of generated code. >> >> Most of scratch register usages relate to `AddressLiteral` on x86_64. In such case the argument is turned into a default one (with `noreg` as a default) and implementation asserts that scratch register should be provided when the address is not guaranteed to be always reachable. >> >> Otherwise, scratch register argument is required to be explicitly provided. >> >> The only case left (mostly) intact is `call(AddressLiteral)`, but I switched it from `rscratch` (`r10`) to `rax`. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 (w/ -XX:+-ForceUnreachable) >> - [x] x86_32 build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > x86_32 Thanks, Aleksey. ------------- PR: https://git.openjdk.org/jdk/pull/10003 From vlivanov at openjdk.org Tue Aug 30 18:48:05 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 30 Aug 2022 18:48:05 GMT Subject: Integrated: 8292878: x86: Make scratch register usage explicit in assembler code In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 18:42:28 GMT, Vladimir Ivanov wrote: > Improve MacroAssembler API and make scratch register usages explicit at use sites. > > Different parts of JVM have different assumptions about scratch registers and > implicit assumptions in MacroAssembler makes it harder to reason about the > correctness of generated code. > > Most of scratch register usages relate to `AddressLiteral` on x86_64. In such case the argument is turned into a default one (with `noreg` as a default) and implementation asserts that scratch register should be provided when the address is not guaranteed to be always reachable. > > Otherwise, scratch register argument is required to be explicitly provided. > > The only case left (mostly) intact is `call(AddressLiteral)`, but I switched it from `rscratch` (`r10`) to `rax`. > > Testing: > - [x] hs-tier1 - hs-tier4 (w/ -XX:+-ForceUnreachable) > - [x] x86_32 build This pull request has now been integrated. Changeset: 6e248279 Author: Vladimir Ivanov URL: https://git.openjdk.org/jdk/commit/6e248279cfb44cf6a1b5156a41200bf9c166388f Stats: 1210 lines in 32 files changed: 230 ins; 143 del; 837 mod 8292878: x86: Make scratch register usage explicit in assembler code Reviewed-by: kvn, shade ------------- PR: https://git.openjdk.org/jdk/pull/10003 From coleenp at openjdk.org Tue Aug 30 19:31:00 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 Aug 2022 19:31:00 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v5] In-Reply-To: References: Message-ID: > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add comment about key,value. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10043/files - new: https://git.openjdk.org/jdk/pull/10043/files/ac67b187..b549a473 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=03-04 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From iklam at openjdk.org Tue Aug 30 19:32:23 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 30 Aug 2022 19:32:23 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v4] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 12:24:33 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > David's comments Looks good overall and seems to be equivalent to the old code. Just a couple of nits. src/hotspot/share/classfile/protectionDomainCache.cpp line 162: > 160: // Purge any deleted entries outside of the SystemDictionary_lock. > 161: purge_deleted_entries(); > 162: int oops_removed = purge_entries_from_table(); // reacquires SD lock It's confusing to have two similarly named functions (purge_deleted_entries and purge_entries_from_table). Maybe the two functions should be combined into a single `purge()` function that performs the two steps? src/hotspot/share/classfile/protectionDomainCache.hpp line 35: > 33: // The amount of different protection domains used is typically magnitudes smaller > 34: // than the number of system dictionary entries (loaded classes). > 35: class ProtectionDomainCacheTable : public AllStatic { How about adding a comment to say what this table maps from/to? Something like: // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are // registered by DictionaryEntry::add_protection_domain() to a unique WeakHandle. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/10043 From kbarrett at openjdk.org Tue Aug 30 19:45:18 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 30 Aug 2022 19:45:18 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> Message-ID: On Tue, 30 Aug 2022 17:22:55 GMT, Stefan Karlsson wrote: >> I see that now. I wandered into the diffs to quickly see what this is about and saw this without the comment and it looked strange. Maybe _0X would also look strange, or even _0_X. I assume these alternatives have been discussed and discarded. > > They have not been discussed. I looked for a pragmatic solution to the problem that parts of the code have different formatting requirements, and then selected one naming convention that I liked. This can still be changed if we can agree on a another / better naming convention. I don't have a strong opinion, just offering a couple ideas. I'm not sure the additional underscore between the modifiers is worthwhile. I like having the "X" before the extension part. I thought about "Z" (for zero) instead of "0", but think I prefer being more literal. So my preference would be "XXX_FORMAT_X0" instead of "XXX_FORMAT_X_0". But that's a pretty weak preference. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From kbarrett at openjdk.org Tue Aug 30 19:48:31 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 30 Aug 2022 19:48:31 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> Message-ID: On Tue, 30 Aug 2022 12:58:38 GMT, Stefan Karlsson wrote: >> Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. >> >> This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. >> >> We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. >> >> I'd like to suggest that we use a convention to specify what we want. This is the current proposal: >> >> // Guide to the suffixes used in the format specifiers for integers: >> // - print the decimal value: 745565 >> // _X - print as hexadecimal, without leading 0s: 0x12345 >> // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >> // _H - print as hexadecimal, without 0x prefix >> // _W(w) - prints w sized string with the given value right >> // adjusted. Use -w to print left adjusted. >> // >> // Note that the PTR format specifiers print using 0x with leading zeros, >> // just like the _X_0 version for integers. >> >> >> The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Move INTPTR_FORMAT_H_W to Shenandoah src/hotspot/share/utilities/globalDefinitions.hpp line 97: > 95: // _X - print as hexadecimal, without leading 0s: 0x12345 > 96: // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 > 97: // _H - print as hexadecimal, without 0x prefix I think we don't have any of these "H" suffixed names. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From stefank at openjdk.org Tue Aug 30 20:03:14 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 30 Aug 2022 20:03:14 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> Message-ID: On Tue, 30 Aug 2022 19:46:00 GMT, Kim Barrett wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Move INTPTR_FORMAT_H_W to Shenandoah > > src/hotspot/share/utilities/globalDefinitions.hpp line 97: > >> 95: // _X - print as hexadecimal, without leading 0s: 0x12345 >> 96: // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >> 97: // _H - print as hexadecimal, without 0x prefix > > I think we don't have any of these "H" suffixed names. The patch has one usage of SIZE_FORMAT_H_W. We could of course just inline that usage, if you think that makes more sense. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From stefank at openjdk.org Tue Aug 30 20:07:06 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 30 Aug 2022 20:07:06 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> Message-ID: On Tue, 30 Aug 2022 19:41:23 GMT, Kim Barrett wrote: >> They have not been discussed. I looked for a pragmatic solution to the problem that parts of the code have different formatting requirements, and then selected one naming convention that I liked. This can still be changed if we can agree on a another / better naming convention. > > I don't have a strong opinion, just offering a couple ideas. I'm not sure the additional underscore between the modifiers is worthwhile. I like having the "X" before the extension part. I thought about "Z" (for zero) instead of "0", but think I prefer being more literal. So my preference would be "XXX_FORMAT_X0" instead of "XXX_FORMAT_X_0". But that's a pretty weak preference. An alternative could be to switch so that _X means 0x and zero padding, and then use another letter to denote the case where we don't want the leading zeros. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From coleenp at openjdk.org Tue Aug 30 20:18:40 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 Aug 2022 20:18:40 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v6] In-Reply-To: References: Message-ID: > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Ioi comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10043/files - new: https://git.openjdk.org/jdk/pull/10043/files/b549a473..3634521f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=04-05 Stats: 56 lines in 2 files changed: 25 ins; 28 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Tue Aug 30 20:18:40 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 Aug 2022 20:18:40 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v5] In-Reply-To: References: Message-ID: <70cl_bIxCFd16WL9j-O__wWS6MHJQuVR8fwe7vVDptY=.a8cbb465-095f-4170-b4fb-e26f502e33a6@github.com> On Tue, 30 Aug 2022 19:31:00 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about key,value. Thank you for reviewing, Ioi. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Tue Aug 30 20:18:41 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 Aug 2022 20:18:41 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v4] In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 18:20:26 GMT, Ioi Lam wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> David's comments > > src/hotspot/share/classfile/protectionDomainCache.cpp line 162: > >> 160: // Purge any deleted entries outside of the SystemDictionary_lock. >> 161: purge_deleted_entries(); >> 162: int oops_removed = purge_entries_from_table(); // reacquires SD lock > > It's confusing to have two similarly named functions (purge_deleted_entries and purge_entries_from_table). Maybe the two functions should be combined into a single `purge()` function that performs the two steps? I'll put purge_entries_from_table back in the mainline of this function where it used to be. I'd separated it because it was long. purge_deleted_entries should be its own function because it goes to a safepoint so it's special. > src/hotspot/share/classfile/protectionDomainCache.hpp line 35: > >> 33: // The amount of different protection domains used is typically magnitudes smaller >> 34: // than the number of system dictionary entries (loaded classes). >> 35: class ProtectionDomainCacheTable : public AllStatic { > > How about adding a comment to say what this table maps from/to? Something like: > > // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are > // registered by DictionaryEntry::add_protection_domain() to a unique WeakHandle. Okay, I added your comment. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Tue Aug 30 23:00:55 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 Aug 2022 23:00:55 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> Message-ID: On Tue, 30 Aug 2022 20:03:26 GMT, Stefan Karlsson wrote: >> I don't have a strong opinion, just offering a couple ideas. I'm not sure the additional underscore between the modifiers is worthwhile. I like having the "X" before the extension part. I thought about "Z" (for zero) instead of "0", but think I prefer being more literal. So my preference would be "XXX_FORMAT_X0" instead of "XXX_FORMAT_X_0". But that's a pretty weak preference. > > An alternative could be to switch so that _X means 0x and zero padding, and then use another letter to denote the case where we don't want the leading zeros. INTPTR_FORMAT zero pads, right? and that seems to be more prevalent in the code. So THING_FORMAT_X seems like it should also pad since that's usually(?) what we want. So I like this idea. Then thinking of a way to say not to pad is hard - how about THING_FORMAT_X_NZ (NZ for no zero). Are there a lot of these? Sorry for the drive by comments. If other people are fine, I'm okay with the names. I was just a bit surprised by the trailing zero on first read. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From duke at openjdk.org Tue Aug 30 23:52:37 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Aug 2022 23:52:37 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive Message-ID: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode. Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier. Testing with fastdebug build: - [x] hotspot_loom - [x] jdk_loom - [x] hotspot_loom in Shenandoah IU mode - [x] jdk_loom in Shenandoah IU mode - [x] hotspot_loom in Shenandoah IU + aggressive - [x] jdk_loom in Shenandoah IU + aggressive Signed-off-by: Ashutosh Mehra ------------- Commit messages: - 8288129: Shenandoah: Skynet test crashed with iu + aggressive Changes: https://git.openjdk.org/jdk/pull/10089/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10089&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288129 Stats: 36 lines in 9 files changed: 27 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10089.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10089/head:pull/10089 PR: https://git.openjdk.org/jdk/pull/10089 From duke at openjdk.org Tue Aug 30 23:52:37 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Aug 2022 23:52:37 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> Message-ID: On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra wrote: > Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode. > > Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier. > > Testing with fastdebug build: > > - [x] hotspot_loom > - [x] jdk_loom > - [x] hotspot_loom in Shenandoah IU mode > - [x] jdk_loom in Shenandoah IU mode > - [x] hotspot_loom in Shenandoah IU + aggressive > - [x] jdk_loom in Shenandoah IU + aggressive > > Signed-off-by: Ashutosh Mehra I got couple of intermittent failures in jdk_loom with Shenandoah IU+aggressive mode, but I reproduced the same intermittent failure without the changes as well, so probably a latent bug. Tests that failed are: - java/lang/management/ThreadMXBean/LockedSynchronizers.java - java/lang/management/ThreadMXBean/MyOwnSynchronizer.java Frequency of failure is around 1/10. Reason for the failure is the following assertion: # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/shenandoahBarrierSet.inline.hpp:246 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp:246), pid=1427500, tid=1427517 # Error: Shenandoah assert_not_in_cset failed; Object should not be in collection set Referenced from: interior location: 0x00007fc020003280 outside of Java heap 0x00007fc020003280 points into unknown readable memory: 0x0000000000000000 | 00 00 00 00 00 00 00 00 Object: 0x00000000d01b6840 - klass 0x0000000800215ed8 java.util.concurrent.locks.ReentrantLock$NonfairSync not allocated after mark start not after update watermark marked strong not marked weak in collection set mark: mark(is_neutral no_hash age=0) region: | 6|CS |BTE d0180000, d01bff00, d01c0000|TAMS d01bff00|UWM d01bff00|U 255K|T 255K|G 0B|S 0B|L 49040B|CP 0 Forwardee: (the object itself) @fisk @rkennke if these changes look good, I will close the previous pr. ------------- PR: https://git.openjdk.org/jdk/pull/10089 From sspitsyn at openjdk.org Wed Aug 31 00:05:07 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 31 Aug 2022 00:05:07 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 21:16:22 GMT, Alex Menkov wrote: > The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) > > cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. > After successful RedefineClasses it should be reset. > The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. src/hotspot/share/classfile/klassFactory.cpp line 135: > 133: if (state != NULL) { > 134: Klass* k = state->get_class_being_redefined(); > 135: // use cached_class_file only for RetransformClasses More detailed comment would be nice to have here to explain in what scenario this change is needed. ------------- PR: https://git.openjdk.org/jdk/pull/10032 From fjiang at openjdk.org Wed Aug 31 00:51:04 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 31 Aug 2022 00:51:04 GMT Subject: RFR: 8293065: Zero build failure on AArch64 and RISCV64 after JDK-8293007 In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 07:04:05 GMT, Erik ?sterlund wrote: >> [JDK-8293007](https://bugs.openjdk.org/browse/JDK-8293007) changes the `AARCH64_PORT_ONLY` macro into `AARCH64`, which is not an equivalent replacement. >> This patch also fixes the same zero build failure on RISCV64. >> >> Testing: >> >> - Linux AArch64 zero release build >> - Linux AArch64 server release build >> - Linux RISCV64 zero release build >> - Linux RISCV64 server release build > > Looks good. @fisk @RealFYang @yadongw @vnkozlov -- Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10075 From fjiang at openjdk.org Wed Aug 31 00:59:32 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 31 Aug 2022 00:59:32 GMT Subject: Integrated: 8293065: Zero build failure on AArch64 and RISCV64 after JDK-8293007 In-Reply-To: References: Message-ID: <4Lqjm3qThuOcubernXOOsAlmx6Z3KGUURPeeilzGQLw=.5abf1f9a-5a4e-442a-b5e1-4fe5bfeeeb2e@github.com> On Tue, 30 Aug 2022 06:17:19 GMT, Feilong Jiang wrote: > [JDK-8293007](https://bugs.openjdk.org/browse/JDK-8293007) changes the `AARCH64_PORT_ONLY` macro into `AARCH64`, which is not an equivalent replacement. > This patch also fixes the same zero build failure on RISCV64. > > Testing: > > - Linux AArch64 zero release build > - Linux AArch64 server release build > - Linux RISCV64 zero release build > - Linux RISCV64 server release build This pull request has now been integrated. Changeset: 2d7792c7 Author: Feilong Jiang Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/2d7792c78308503ad291fae51378c213d3e23683 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8293065: Zero build failure on AArch64 and RISCV64 after JDK-8293007 Reviewed-by: eosterlund, fyang, yadongwang, kvn ------------- PR: https://git.openjdk.org/jdk/pull/10075 From fyang at openjdk.org Wed Aug 31 01:26:06 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 31 Aug 2022 01:26:06 GMT Subject: RFR: 8293035: Cleanup MacroAssembler::movoop code patching logic aarch64 riscv [v2] In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 07:40:47 GMT, Axel Boldt-Christmas wrote: >> Cleanup MacroAssembler::movoop logic with respect to code patching on aarch64 and riscv. >> >> Remove the `bool immediate` argument as it is only used with the value `true` in `void MacroAssembler::movoop(Register dst, jobject obj, bool immediate)` >> >> Make comments and logic more clear and easier to read. >> >> Testing: osx, linux aarch64 tier 1-3 > > Axel Boldt-Christmas 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 remote-tracking branch 'upstream/master' into JDK-8293035 > - 8293035: Cleanup MacroAssembler::movoop code patching logic aarch64 riscv Updated changes look good to me. Also performed tier1 test on linux-riscv64 platform. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10065 From jbhateja at openjdk.org Wed Aug 31 05:05:28 2022 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 31 Aug 2022 05:05:28 GMT Subject: Integrated: 8291649: multiple tests failing with -Xcomp after JDK-8290034 In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 17:58:39 GMT, Jatin Bhateja wrote: > Hi, > > This bug fix patch fixes the incorrect computation during constant folding of Reverse[IL] IR node. > A new utility class has been added to optimize computation of reverse_bit operation using GCC built-ins. > > Kindly review and share your feedback. > > Best Regards, > Jatin This pull request has now been integrated. Changeset: 38377d5e Author: Jatin Bhateja URL: https://git.openjdk.org/jdk/commit/38377d5eb785829525739479a77dec250c477efc Stats: 235 lines in 5 files changed: 214 ins; 17 del; 4 mod 8291649: multiple tests failing with -Xcomp after JDK-8290034 Co-authored-by: Kim Barrett Co-authored-by: John R Rose Reviewed-by: kbarrett, jrose ------------- PR: https://git.openjdk.org/jdk/pull/9987 From dholmes at openjdk.org Wed Aug 31 05:18:25 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 31 Aug 2022 05:18:25 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Tue, 30 Aug 2022 18:13:21 GMT, Ioi Lam wrote: >> compute_hash() is always called on a live WeakHandle so will never return null. > > I think you should add an assert that the `protection_domain.resolve()` never returns null, with a comment explaining why. I agree. In general if code is using WeakHandle's then I would expect to see null checks. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Wed Aug 31 05:18:29 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 31 Aug 2022 05:18:29 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Mon, 29 Aug 2022 12:11:03 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/protectionDomainCache.cpp line 168: >> >>> 166: } >>> 167: >>> 168: void ProtectionDomainCacheTable::print_on(outputStream* st) { >> >> It is a little disconcerting that `print_on` can no longer be a `const` function! > > It's static, so it can't. Ah I see - I hadn't noticed it was now static. >> src/hotspot/share/classfile/protectionDomainCache.cpp line 186: >> >>> 184: >>> 185: // The object_no_keepalive() call peeks at the phantomly reachable oop without >>> 186: // keeping it alive. This is okay to do in the VM thread state if it is not >> >> You don't call `object_no_keepalive()` any more > > This one (not the one I removed), is called by dictionary.cpp - the pd_set is a linked list of ProtectionDomainEntry, where we don't keep the WeakHandle alive when looking at the value. I don't understand your point. My point is that the comment no longer seems correct. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Wed Aug 31 05:18:30 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 31 Aug 2022 05:18:30 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v4] In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 20:11:51 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/protectionDomainCache.hpp line 35: >> >>> 33: // The amount of different protection domains used is typically magnitudes smaller >>> 34: // than the number of system dictionary entries (loaded classes). >>> 35: class ProtectionDomainCacheTable : public AllStatic { >> >> How about adding a comment to say what this table maps from/to? Something like: >> >> // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are >> // registered by DictionaryEntry::add_protection_domain() to a unique WeakHandle. > > Okay, I added your comment. I still can't decipher what this "map" actually holds. What does the unique WeakHandle actually refer to? ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Wed Aug 31 05:37:07 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 31 Aug 2022 05:37:07 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> Message-ID: On Tue, 30 Aug 2022 12:58:38 GMT, Stefan Karlsson wrote: >> Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. >> >> This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. >> >> We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. >> >> I'd like to suggest that we use a convention to specify what we want. This is the current proposal: >> >> // Guide to the suffixes used in the format specifiers for integers: >> // - print the decimal value: 745565 >> // _X - print as hexadecimal, without leading 0s: 0x12345 >> // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >> // _H - print as hexadecimal, without 0x prefix >> // _W(w) - prints w sized string with the given value right >> // adjusted. Use -w to print left adjusted. >> // >> // Note that the PTR format specifiers print using 0x with leading zeros, >> // just like the _X_0 version for integers. >> >> >> The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Move INTPTR_FORMAT_H_W to Shenandoah Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10042 From dholmes at openjdk.org Wed Aug 31 05:37:09 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 31 Aug 2022 05:37:09 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v2] In-Reply-To: References: Message-ID: <_DnrfxicUY28TYEQzyKuRUcQWEToHhx82cXuhF7-NjA=.4bbc3037-9555-4339-ac93-c81500669da9@github.com> On Mon, 29 Aug 2022 12:15:17 GMT, David Holmes wrote: >>> (And yes we have to cast the ptrs to int using p2i but that is just because of compiler limitations/issues ... which raises the recurring old question of "have we finally reached a point where we can use %p cross-platform?") >> >> One motivation for using PTR_FORMAT instead of %p, is to get consistent output on all platforms. I ran the following on different OSes: >> >> tty->print_cr("%p " PTR_FORMAT, (void*)0x12345678, (uintptr_t)0x12345678); >> >> And the result is: >> >> Linux: 0x12345678 0x0000000012345678 >> macOS: 0x12345678 0x0000000012345678 >> Win: 0x0000000012345678 0x0000000012345678 >> >> >> I also tested getting zero padding on Linux, but the compiler informs me that that's not allowed: `error: '0' flag used with '%p' gnu_printf format"`. > >> One motivation for using PTR_FORMAT instead of %p, is to get consistent output on all platforms. > > Yes that has always been the problem, but I wondered whether this issue was perhaps finally resolved. Based on your results we seem closer - they all have leading 0x - but they still differ in leading zeroes. I have a recollection now that someone tried using %p fairly recently (ie last 12-24 months) and also discovered this. Kind of sad that something so conceptually simple has proven to be so difficult to get right. > @dholmes-ora Do you have any actionable items that you want me to do for this PR? I think we need to pin down the conventions on which format to use when but that can be a future RFE as it is very subjective. So I think I'm okay with this as-is. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From dholmes at openjdk.org Wed Aug 31 05:37:10 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 31 Aug 2022 05:37:10 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> Message-ID: <2MgDjJHNb7kjnpu5WdndmSDopHja8tdeqpXyBlyLlo8=.e4624a90-3385-407b-a38f-205b67031c7f@github.com> On Tue, 30 Aug 2022 22:57:26 GMT, Coleen Phillimore wrote: >> An alternative could be to switch so that _X means 0x and zero padding, and then use another letter to denote the case where we don't want the leading zeros. > > INTPTR_FORMAT zero pads, right? and that seems to be more prevalent in the code. So THING_FORMAT_X seems like it should also pad since that's usually(?) what we want. So I like this idea. Then thinking of a way to say not to pad is hard - how about THING_FORMAT_X_NZ (NZ for no zero). Are there a lot of these? > Sorry for the drive by comments. If other people are fine, I'm okay with the names. I was just a bit surprised by the trailing zero on first read. I think the naming convention in the PR is as good as any other - it is something new that we have to get used to. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From stefank at openjdk.org Wed Aug 31 06:50:07 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 31 Aug 2022 06:50:07 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v5] In-Reply-To: References: Message-ID: > Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. > > This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. > > We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. > > I'd like to suggest that we use a convention to specify what we want. This is the current proposal: > > // Guide to the suffixes used in the format specifiers for integers: > // - print the decimal value: 745565 > // _X - print as hexadecimal, without leading 0s: 0x12345 > // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 > // _H - print as hexadecimal, without 0x prefix > // _W(w) - prints w sized string with the given value right > // adjusted. Use -w to print left adjusted. > // > // Note that the PTR format specifiers print using 0x with leading zeros, > // just like the _X_0 version for integers. > > > The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Removed extraneous 0x ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10042/files - new: https://git.openjdk.org/jdk/pull/10042/files/53d40ef5..dd0e1ae0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=03-04 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10042.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10042/head:pull/10042 PR: https://git.openjdk.org/jdk/pull/10042 From stefank at openjdk.org Wed Aug 31 07:10:19 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 31 Aug 2022 07:10:19 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v6] In-Reply-To: References: Message-ID: > Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. > > This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. > > We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. > > I'd like to suggest that we use a convention to specify what we want. This is the current proposal: > > // Guide to the suffixes used in the format specifiers for integers: > // - print the decimal value: 745565 > // _X - print as hexadecimal, without leading 0s: 0x12345 > // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 > // _H - print as hexadecimal, without 0x prefix > // _W(w) - prints w sized string with the given value right > // adjusted. Use -w to print left adjusted. > // > // Note that the PTR format specifiers print using 0x with leading zeros, > // just like the _X_0 version for integers. > > > The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Remove _H variants ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10042/files - new: https://git.openjdk.org/jdk/pull/10042/files/dd0e1ae0..38dc2153 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=04-05 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10042.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10042/head:pull/10042 PR: https://git.openjdk.org/jdk/pull/10042 From aboldtch at openjdk.org Wed Aug 31 07:46:16 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 31 Aug 2022 07:46:16 GMT Subject: Integrated: 8293035: Cleanup MacroAssembler::movoop code patching logic aarch64 riscv In-Reply-To: References: Message-ID: <79KE4qqSFI-Omo0t23o_1QZXJrCKQaUibGhuDXj5x00=.3a603206-8962-49e5-b830-31a66c04f82c@github.com> On Mon, 29 Aug 2022 15:16:23 GMT, Axel Boldt-Christmas wrote: > Cleanup MacroAssembler::movoop logic with respect to code patching on aarch64 and riscv. > > Remove the `bool immediate` argument as it is only used with the value `true` in `void MacroAssembler::movoop(Register dst, jobject obj, bool immediate)` > > Make comments and logic more clear and easier to read. > > Testing: osx, linux aarch64 tier 1-3 This pull request has now been integrated. Changeset: 9e3176bd Author: Axel Boldt-Christmas Committer: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/9e3176bd09c7210ccb125491abb6a6a4d852b6c6 Stats: 47 lines in 13 files changed: 12 ins; 14 del; 21 mod 8293035: Cleanup MacroAssembler::movoop code patching logic aarch64 riscv Reviewed-by: eosterlund, fyang ------------- PR: https://git.openjdk.org/jdk/pull/10065 From fyang at openjdk.org Wed Aug 31 08:10:18 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 31 Aug 2022 08:10:18 GMT Subject: RFR: 8293050: RISC-V: Remove redundant non-null assertions about macro-assembler In-Reply-To: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> References: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> Message-ID: On Tue, 30 Aug 2022 11:12:30 GMT, Fei Yang wrote: > There are some non-null assertions about macro-assembler in riscv-specific code. Most of them are there to make some internal code-check tools happy. We should remove those redundant assertions to make the code clean. > > Tested with tier1 hotspot on linux-riscv64 unmatched. @shipilev : Want to take a look? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10079 From yadongwang at openjdk.org Wed Aug 31 08:14:11 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Wed, 31 Aug 2022 08:14:11 GMT Subject: RFR: 8293050: RISC-V: Remove redundant non-null assertions about macro-assembler In-Reply-To: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> References: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> Message-ID: On Tue, 30 Aug 2022 11:12:30 GMT, Fei Yang wrote: > There are some non-null assertions about macro-assembler in riscv-specific code. Most of them are there to make some internal code-check tools happy. We should remove those redundant assertions to make the code clean. > > Tested with tier1 hotspot on linux-riscv64 unmatched. lgtm(not a reviewer) ------------- Marked as reviewed by yadongwang (Author). PR: https://git.openjdk.org/jdk/pull/10079 From stuefe at openjdk.org Wed Aug 31 08:31:00 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 31 Aug 2022 08:31:00 GMT Subject: RFR: JDK-8293114: GC should trim the native heap Message-ID: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> This RFE adds the option to auto-trim the Glibc heap as part of the GC cycle. If the VM process suffered high temporary malloc spikes (regardless whether from JVM- or user code), this could recover significant amounts of memory. We discussed this a year ago [1], but the item got pushed to the bottom of my work pile, therefore it took longer than I thought. ### Motivation The Glibc allocator is reluctant to return memory to the OS, much more so than other allocators. Temporary malloc spikes often carry over as permanent RSS increase. Note that C-heap retention is difficult to observe. Since it is freed memory, it won't show up in NMT, it is just a part of private RSS. Theoretically, retained memory is not lost since it will be reused by future mallocs. Retaining memory is therefore a bet on the future behavior of the app. The allocator bets on the application needing memory in the near future, and to satisfy that need via malloc. But an app's malloc load can fluctuate wildly, with temporary spikes and long idle periods. And if the app rolls its own custom allocators atop of mmap, as hotspot does, a lot of that memory cannot be reused even though it counts toward its memory footprint. To help, Glibc exports an API to trim the C-heap: `malloc_trim(3)`. With JDK 18 [2], SAP contributed a new jcmd command to *manually* trim the C-heap on Linux. This RFE adds a complementary way to trim automatically. #### Is this even a problem? Do we have high malloc spikes in the JVM process? We assume that malloc load from hotspot is usually low since hotspot typically clusters allocations into custom areas - metaspace, code heap, arenas. But arenas are subject to Glibc mem retention too. I was surprised by that since I assumed 32k arena chunks were too big to be subject of Glibc retention. But I saw in experiments that high arena peaks often cause lasting RSS increase. And of course, both hotspot and JDK do a lot of finer-granular mallocs outside of custom allocators. But many cases of high memory retention in Glibc I have seen in third-party JNI code. Libraries allocate large buffers via malloc as temporary buffers. In fact, since we introduced the jcmd "System.trim_native_heap", some of our customers started to call this command periodically in scripts to counter these issues. Therefore I think while high malloc spikes are atypical for a JVM process, they can happen. Having a way to auto-trim the native heap makes sense. ### When should we trim? We want to trim when we know there is a lull in malloc activity coming. But we have no knowledge of the future. We could build a heuristic based on malloc frequency. But on closer inspection that is difficult. We cannot use NMT, since NMT has no complete picture (only knows hotspot) and is usually disabled in production anyway. The only way to get *all* mallocs would be to use Glibc malloc hooks. We have done so in desperate cases at SAP, but Glibc removed malloc hooks in 2.35. It would be a messy solution anyway; best to avoid it. The next best thing is synchronizing with the larger C-heap users in the VM: compiler and GC. But compiler turns out not to be such a problem, since the compiler uses arenas, and arena chunks are buffered in a free pool with a five-second delay. That means compiler activity that happens in bursts, like at VM startup, will just shuffle arena chunks around from/to the arena free pool, never bothering to call malloc or free. That leaves the GC, which was also the experts' recommendation in last year's discussion [1]. Most GCs do uncommit, and trimming the native heap fits well into this. And we want to time the trim to not get into the way of a GC. Plus, integrating trims into the GC cycle lets us reuse GC logging and timing, thereby making RSS changes caused by trim-native visible to the analyst. ### How it works: Patch adds new options (experimental for now, and shared among all GCs): -XX:+GCTrimNativeHeap -XX:GCTrimNativeHeapInterval= (defaults to 60) `GCTrimNativeHeap` is off by default. If enabled, it will cause the VM to trim the native heap on full GCs as well as periodically. The period is defined by `GCTrimNativeHeapInterval`. Periodic trimming can be completely switched off with `GCTrimNativeHeapInterval=0`; in that case, we will only trim on full GCs. ### Examples: This is an artificial test that causes two high malloc spikes with long idle periods. Observe how RSS recovers with trim but stays up without trim. The trim interval was set to 15 seconds for the test, and no GC was invoked here; this is periodic trimming. ![alloc-test](http://cr.openjdk.java.net/~stuefe/other/autotrim/rss-all-collectors.png) (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-all.sh) ) Spring pet clinic boots up, then idles. Once with, once without trim, with the trim interval at 60 seconds default. Of course, if it were actually doing something instead of idling, trim effects would be smaller. But the point of trimming is to recover memory in idle periods. ![petclinic bootup](http://cr.openjdk.java.net/~stuefe/other/autotrim/spring-petclinic-rss-with-and-without-trim.png)) (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-petclinic-boot.sh) ) ### Implementation One problem I faced when implementing this was that trimming was non-interruptable. GCs usually split the uncommit work into smaller portions, which is impossible for `malloc_trim()`. So very slow trims could introduce longer GC pauses. I did not want this, therefore I implemented two ways to trim: 1) GCs can opt to trim asynchronously. In that case, a `NativeTrimmer` thread runs on behalf of the GC and takes care of all trimming. The GC just nudges the `NativeTrimmer` at the end of its GC cycle, but the trim itself runs concurrently. 2) GCs can do the trim inside their own thread, synchronously. It will have to wait until the trim is done. (1) has the advantage of giving us periodic trims even without GC activity (Shenandoah does this out of the box). #### Serial Serial does the trimming synchronously as part of a full GC, and only then. I did not want to spawn a separate thread for the SerialGC. Therefore Serial is the only GC that does not offer periodic trimming, it just trims on full GC. #### Parallel, G1, Z All of them do the trimming asynchronously via `NativeTrimmer`. They schedule the native trim at the end of a full collection. They also pause the trimming at the beginning of a cycle to not trim during GCs. #### Shenandoah Shenandoah does the trimming synchronously in its service thread, similar to how it handles uncommits. Since the service thread already runs concurrently and continuously, it can do periodic trimming; no need to spin a new thread. And this way we can reuse the Shenandoah timing classes. ### Patch details - adds three new functions to the `os` namespace: - `os::trim_native_heap()` implementing trim - `os::can_trim_native_heap()` and `os::should_trim_native_heap()` to return whether platform supports trimming resp. whether the platform considers trimming to be useful. - replaces implementation of the cmd "System.trim_native_heap" with the new `os::trim_native_heap` - provides a new wrapper function wrapping the tedious `mallinfo()` vs `mallinfo2()` business: `os::Linux::get_mallinfo()` - adds a GC-shared utility class, `GCTrimNative`, that takes care of trimming and GC-logging and houses the `NativeTrimmer` thread class. - adds a regression test ### Tests Tested older Glibc (2.31), and newer Glibc (2.35) (`mallinfo()` vs` mallinfo2()`), on Linux x64. The rest of the tests will be done by GHA and in our SAP nightlies. ### Remarks #### How about other allocators? I have seen this retention problem mainly with the Glibc and the AIX libc. Muslc returns memory more eagerly to the OS. I also tested with jemalloc and found it also reclaims more aggressively, therefore I don't think MacOS or BSD are affected that much by retention either. #### Trim costs? Trim-native is a tradeoff between memory and performance. We pay - The cost to do the trim depends on how much is trimmed. Time ranges on my machine between < 1ms for no-op trims, to ~800ms for 32GB trims. - The cost for re-acquiring the memory, should the memory be needed again, is the second cost factor. #### Predicting malloc_trim effects? `ShenandoahUncommit` avoids uncommits if they are not necessary, thus avoiding work and gc log spamming. I liked that and tried to follow that example. Tried to devise a way to predict the effect trim could have based on allocator info from mallinfo(3). That was quite frustrating since the documentation was confusing and I had to do a lot of experimenting. In the end, I came up with a heuristic to prevent obviously pointless trim attempts; see `os::should_trim_native_heap()`. I am not completely happy with it. #### glibc.malloc.trim_threshold? glibc has a tunable that looks like it could influence the willingness of Glibc to return memory to the OS, the "trim_threshold". In practice, I could not get it to do anything useful. Regardless of the setting, it never seemed to influence the trimming behavior. Even if it would work, I'm not sure we'd want to use that, since by doing malloc_trim manually we can space out the trims as we see fit, instead of paying the trim price for free(3). - [1] https://mail.openjdk.org/pipermail/hotspot-dev/2021-August/054323.html - [2] https://bugs.openjdk.org/browse/JDK-8269345 ------------- Commit messages: - wip - Fixes and Simplifications - some simplifications - trim-native Changes: https://git.openjdk.org/jdk/pull/10085/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10085&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293114 Stats: 1142 lines in 26 files changed: 1034 ins; 73 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/10085.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10085/head:pull/10085 PR: https://git.openjdk.org/jdk/pull/10085 From shade at openjdk.org Wed Aug 31 09:08:22 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 31 Aug 2022 09:08:22 GMT Subject: RFR: 8293050: RISC-V: Remove redundant non-null assertions about macro-assembler In-Reply-To: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> References: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> Message-ID: On Tue, 30 Aug 2022 11:12:30 GMT, Fei Yang wrote: > There are some non-null assertions about macro-assembler in riscv-specific code. Most of them are there to make some internal code-check tools happy. We should remove those redundant assertions to make the code clean. > > Tested with tier1 hotspot on linux-riscv64 unmatched. Looks okay, but I wonder if we want to do the fence change separately. src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp line 529: > 527: __ push(state); > 528: __ call_VM(noreg, runtime_entry); > 529: __ membar(MacroAssembler::AnyAny); This does not look like a "redundant non-null assertion" :) ------------- PR: https://git.openjdk.org/jdk/pull/10079 From fyang at openjdk.org Wed Aug 31 09:23:14 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 31 Aug 2022 09:23:14 GMT Subject: RFR: 8293050: RISC-V: Remove redundant non-null assertions about macro-assembler [v2] In-Reply-To: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> References: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> Message-ID: <1cPWYSyRzizVY7XvA2ZQWJlJTRZ28G-jK4Xp5TgUX_I=.e2b5f26e-46de-48f0-880e-061b669b07df@github.com> > There are some non-null assertions about macro-assembler in riscv-specific code. Most of them are there to make some internal code-check tools happy. We should remove those redundant assertions to make the code clean. > > Tested with tier1 hotspot on linux-riscv64 unmatched. Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10079/files - new: https://git.openjdk.org/jdk/pull/10079/files/126780fb..3547131e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10079&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10079&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10079.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10079/head:pull/10079 PR: https://git.openjdk.org/jdk/pull/10079 From fyang at openjdk.org Wed Aug 31 09:23:15 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 31 Aug 2022 09:23:15 GMT Subject: RFR: 8293050: RISC-V: Remove redundant non-null assertions about macro-assembler [v2] In-Reply-To: References: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> Message-ID: On Wed, 31 Aug 2022 09:05:35 GMT, Aleksey Shipilev wrote: >> Fei Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix > > src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp line 529: > >> 527: __ push(state); >> 528: __ call_VM(noreg, runtime_entry); >> 529: __ membar(MacroAssembler::AnyAny); > > This does not look like a "redundant non-null assertion" :) OK. I think I can propose this change in a seperate PR. I will see if I can find other similar occurences. See updated change. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10079 From shade at openjdk.org Wed Aug 31 09:36:22 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 31 Aug 2022 09:36:22 GMT Subject: RFR: 8293050: RISC-V: Remove redundant non-null assertions about macro-assembler [v2] In-Reply-To: <1cPWYSyRzizVY7XvA2ZQWJlJTRZ28G-jK4Xp5TgUX_I=.e2b5f26e-46de-48f0-880e-061b669b07df@github.com> References: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> <1cPWYSyRzizVY7XvA2ZQWJlJTRZ28G-jK4Xp5TgUX_I=.e2b5f26e-46de-48f0-880e-061b669b07df@github.com> Message-ID: <5RMf75sNZ44KZCtGx1doAp5wdqOfpuMqfqQcaoBO7tw=.6008dada-c569-4f09-81c0-566d48c187c2@github.com> On Wed, 31 Aug 2022 09:23:14 GMT, Fei Yang wrote: >> There are some non-null assertions about macro-assembler in riscv-specific code. Most of them are there to make some internal code-check tools happy. We should remove those redundant assertions to make the code clean. >> >> Tested with tier1 hotspot on linux-riscv64 unmatched. > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Fix Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10079 From fyang at openjdk.org Wed Aug 31 12:25:09 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 31 Aug 2022 12:25:09 GMT Subject: RFR: 8293050: RISC-V: Remove redundant non-null assertions about macro-assembler [v2] In-Reply-To: <1cPWYSyRzizVY7XvA2ZQWJlJTRZ28G-jK4Xp5TgUX_I=.e2b5f26e-46de-48f0-880e-061b669b07df@github.com> References: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> <1cPWYSyRzizVY7XvA2ZQWJlJTRZ28G-jK4Xp5TgUX_I=.e2b5f26e-46de-48f0-880e-061b669b07df@github.com> Message-ID: <-Abh2cnqx3nEqTusRnQ6wr8JLHwn5L-Onzhy2NaN9vg=.dcd28043-de25-43e7-b2f0-b20572a44108@github.com> On Wed, 31 Aug 2022 09:23:14 GMT, Fei Yang wrote: >> There are some non-null assertions about macro-assembler in riscv-specific code. Most of them are there to make some internal code-check tools happy. We should remove those redundant assertions to make the code clean. >> >> Tested with tier1 hotspot on linux-riscv64 unmatched. > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Fix Thanks all the review. I think it's safe to integrate then. ------------- PR: https://git.openjdk.org/jdk/pull/10079 From fyang at openjdk.org Wed Aug 31 12:27:42 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 31 Aug 2022 12:27:42 GMT Subject: Integrated: 8293050: RISC-V: Remove redundant non-null assertions about macro-assembler In-Reply-To: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> References: <81r04bn8bszg-jXlk3uqvCtOjQ7eKp2ALSWGlFHYpZo=.1e808daf-3e64-461c-896a-24ec7ac77fc1@github.com> Message-ID: On Tue, 30 Aug 2022 11:12:30 GMT, Fei Yang wrote: > There are some non-null assertions about macro-assembler in riscv-specific code. Most of them are there to make some internal code-check tools happy. We should remove those redundant assertions to make the code clean. > > Tested with tier1 hotspot on linux-riscv64 unmatched. This pull request has now been integrated. Changeset: 38e67063 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/38e670631587853d0f2b5cad48f8ddbce46cecdb Stats: 53 lines in 8 files changed: 0 ins; 47 del; 6 mod 8293050: RISC-V: Remove redundant non-null assertions about macro-assembler Reviewed-by: fjiang, yadongwang, shade ------------- PR: https://git.openjdk.org/jdk/pull/10079 From stefank at openjdk.org Wed Aug 31 12:30:10 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 31 Aug 2022 12:30:10 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v7] In-Reply-To: References: Message-ID: > Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. > > This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. > > We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. > > I'd like to suggest that we use a convention to specify what we want. This is the current proposal: > > // Guide to the suffixes used in the format specifiers for integers: > // - print the decimal value: 745565 > // _X - print as hexadecimal, without leading 0s: 0x12345 > // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 > // _H - print as hexadecimal, without 0x prefix > // _W(w) - prints w sized string with the given value right > // adjusted. Use -w to print left adjusted. > // > // Note that the PTR format specifiers print using 0x with leading zeros, > // just like the _X_0 version for integers. > > > The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. Stefan Karlsson 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 8292981_unify_integer_format_specifiers - Remove _H variants - Removed extraneous 0x - Move INTPTR_FORMAT_H_W to Shenandoah - Use PTR_FORMAT in AIX code - Fix Shenandoah - 8292981: Unify and restructure integer printing format specifiers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10042/files - new: https://git.openjdk.org/jdk/pull/10042/files/38dc2153..52220b7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=05-06 Stats: 8883 lines in 328 files changed: 2221 ins; 5312 del; 1350 mod Patch: https://git.openjdk.org/jdk/pull/10042.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10042/head:pull/10042 PR: https://git.openjdk.org/jdk/pull/10042 From coleenp at openjdk.org Wed Aug 31 12:34:11 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 31 Aug 2022 12:34:11 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v4] In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 05:15:22 GMT, David Holmes wrote: >> Okay, I added your comment. > > I still can't decipher what this "map" actually holds. What does the unique WeakHandle actually refer to? WeakHandles are wrappers around a pointer to an oop that has been allocated in OopStorage. We cannot hold oops directly in hashtables because then we'd have to tell GC how and when to walk the hashtable. We want to save the oops though because they tell us whether this protection domain has been checked for the class that we're currently loading. The Old Hashtable held WeakHandles. So does this one, except with the wart in that we need the WeakHandle for both lookup and to return a unique WeakHandle for the protection domain oop. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Wed Aug 31 12:39:08 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 31 Aug 2022 12:39:08 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix comments, add assert. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10043/files - new: https://git.openjdk.org/jdk/pull/10043/files/3634521f..8bdc90e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=05-06 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Wed Aug 31 12:39:09 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 31 Aug 2022 12:39:09 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Wed, 31 Aug 2022 05:13:17 GMT, David Holmes wrote: >> This one (not the one I removed), is called by dictionary.cpp - the pd_set is a linked list of ProtectionDomainEntry, where we don't keep the WeakHandle alive when looking at the value. > > I don't understand your point. My point is that the comment no longer seems correct. The first sentence of the comment is correct. I don't know what the second sentence means, so I'll remove it. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Wed Aug 31 13:43:11 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 31 Aug 2022 13:43:11 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: <2MgDjJHNb7kjnpu5WdndmSDopHja8tdeqpXyBlyLlo8=.e4624a90-3385-407b-a38f-205b67031c7f@github.com> References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> <2MgDjJHNb7kjnpu5WdndmSDopHja8tdeqpXyBlyLlo8=.e4624a90-3385-407b-a38f-205b67031c7f@github.com> Message-ID: On Wed, 31 Aug 2022 05:29:39 GMT, David Holmes wrote: >> INTPTR_FORMAT zero pads, right? and that seems to be more prevalent in the code. So THING_FORMAT_X seems like it should also pad since that's usually(?) what we want. So I like this idea. Then thinking of a way to say not to pad is hard - how about THING_FORMAT_X_NZ (NZ for no zero). Are there a lot of these? >> Sorry for the drive by comments. If other people are fine, I'm okay with the names. I was just a bit surprised by the trailing zero on first read. > > I think the naming convention in the PR is as good as any other - it is something new that we have to get used to. It's fine with me whatever you've decided. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From zgu at openjdk.org Wed Aug 31 14:30:08 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 31 Aug 2022 14:30:08 GMT Subject: RFR: JDK-8293114: GC should trim the native heap In-Reply-To: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> References: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> Message-ID: On Tue, 30 Aug 2022 14:35:26 GMT, Thomas Stuefe wrote: > This RFE adds the option to auto-trim the Glibc heap as part of the GC cycle. If the VM process suffered high temporary malloc spikes (regardless whether from JVM- or user code), this could recover significant amounts of memory. > > We discussed this a year ago [1], but the item got pushed to the bottom of my work pile, therefore it took longer than I thought. > > ### Motivation > > The Glibc allocator is reluctant to return memory to the OS, much more so than other allocators. Temporary malloc spikes often carry over as permanent RSS increase. > > Note that C-heap retention is difficult to observe. Since it is freed memory, it won't show up in NMT, it is just a part of private RSS. > > Theoretically, retained memory is not lost since it will be reused by future mallocs. Retaining memory is therefore a bet on the future behavior of the app. The allocator bets on the application needing memory in the near future, and to satisfy that need via malloc. > > But an app's malloc load can fluctuate wildly, with temporary spikes and long idle periods. And if the app rolls its own custom allocators atop of mmap, as hotspot does, a lot of that memory cannot be reused even though it counts toward its memory footprint. > > To help, Glibc exports an API to trim the C-heap: `malloc_trim(3)`. With JDK 18 [2], SAP contributed a new jcmd command to *manually* trim the C-heap on Linux. This RFE adds a complementary way to trim automatically. > > #### Is this even a problem? > > Do we have high malloc spikes in the JVM process? We assume that malloc load from hotspot is usually low since hotspot typically clusters allocations into custom areas - metaspace, code heap, arenas. > > But arenas are subject to Glibc mem retention too. I was surprised by that since I assumed 32k arena chunks were too big to be subject of Glibc retention. But I saw in experiments that high arena peaks often cause lasting RSS increase. > > And of course, both hotspot and JDK do a lot of finer-granular mallocs outside of custom allocators. > > But many cases of high memory retention in Glibc I have seen in third-party JNI code. Libraries allocate large buffers via malloc as temporary buffers. In fact, since we introduced the jcmd "System.trim_native_heap", some of our customers started to call this command periodically in scripts to counter these issues. > > Therefore I think while high malloc spikes are atypical for a JVM process, they can happen. Having a way to auto-trim the native heap makes sense. > > ### When should we trim? > > We want to trim when we know there is a lull in malloc activity coming. But we have no knowledge of the future. > > We could build a heuristic based on malloc frequency. But on closer inspection that is difficult. We cannot use NMT, since NMT has no complete picture (only knows hotspot) and is usually disabled in production anyway. The only way to get *all* mallocs would be to use Glibc malloc hooks. We have done so in desperate cases at SAP, but Glibc removed malloc hooks in 2.35. It would be a messy solution anyway; best to avoid it. > > The next best thing is synchronizing with the larger C-heap users in the VM: compiler and GC. But compiler turns out not to be such a problem, since the compiler uses arenas, and arena chunks are buffered in a free pool with a five-second delay. That means compiler activity that happens in bursts, like at VM startup, will just shuffle arena chunks around from/to the arena free pool, never bothering to call malloc or free. > > That leaves the GC, which was also the experts' recommendation in last year's discussion [1]. Most GCs do uncommit, and trimming the native heap fits well into this. And we want to time the trim to not get into the way of a GC. Plus, integrating trims into the GC cycle lets us reuse GC logging and timing, thereby making RSS changes caused by trim-native visible to the analyst. > > > ### How it works: > > Patch adds new options (experimental for now, and shared among all GCs): > > > -XX:+GCTrimNativeHeap > -XX:GCTrimNativeHeapInterval= (defaults to 60) > > > `GCTrimNativeHeap` is off by default. If enabled, it will cause the VM to trim the native heap on full GCs as well as periodically. The period is defined by `GCTrimNativeHeapInterval`. Periodic trimming can be completely switched off with `GCTrimNativeHeapInterval=0`; in that case, we will only trim on full GCs. > > ### Examples: > > This is an artificial test that causes two high malloc spikes with long idle periods. Observe how RSS recovers with trim but stays up without trim. The trim interval was set to 15 seconds for the test, and no GC was invoked here; this is periodic trimming. > > ![alloc-test](http://cr.openjdk.java.net/~stuefe/other/autotrim/rss-all-collectors.png) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-all.sh) ) > > Spring pet clinic boots up, then idles. Once with, once without trim, with the trim interval at 60 seconds default. Of course, if it were actually doing something instead of idling, trim effects would be smaller. But the point of trimming is to recover memory in idle periods. > > ![petclinic bootup](http://cr.openjdk.java.net/~stuefe/other/autotrim/spring-petclinic-rss-with-and-without-trim.png)) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-petclinic-boot.sh) ) > > > > ### Implementation > > One problem I faced when implementing this was that trimming was non-interruptable. GCs usually split the uncommit work into smaller portions, which is impossible for `malloc_trim()`. > > So very slow trims could introduce longer GC pauses. I did not want this, therefore I implemented two ways to trim: > 1) GCs can opt to trim asynchronously. In that case, a `NativeTrimmer` thread runs on behalf of the GC and takes care of all trimming. The GC just nudges the `NativeTrimmer` at the end of its GC cycle, but the trim itself runs concurrently. > 2) GCs can do the trim inside their own thread, synchronously. It will have to wait until the trim is done. > > (1) has the advantage of giving us periodic trims even without GC activity (Shenandoah does this out of the box). > > #### Serial > > Serial does the trimming synchronously as part of a full GC, and only then. I did not want to spawn a separate thread for the SerialGC. Therefore Serial is the only GC that does not offer periodic trimming, it just trims on full GC. > > #### Parallel, G1, Z > > All of them do the trimming asynchronously via `NativeTrimmer`. They schedule the native trim at the end of a full collection. They also pause the trimming at the beginning of a cycle to not trim during GCs. > > #### Shenandoah > > Shenandoah does the trimming synchronously in its service thread, similar to how it handles uncommits. Since the service thread already runs concurrently and continuously, it can do periodic trimming; no need to spin a new thread. And this way we can reuse the Shenandoah timing classes. > > ### Patch details > > - adds three new functions to the `os` namespace: > - `os::trim_native_heap()` implementing trim > - `os::can_trim_native_heap()` and `os::should_trim_native_heap()` to return whether platform supports trimming resp. whether the platform considers trimming to be useful. > - replaces implementation of the cmd "System.trim_native_heap" with the new `os::trim_native_heap` > - provides a new wrapper function wrapping the tedious `mallinfo()` vs `mallinfo2()` business: `os::Linux::get_mallinfo()` > - adds a GC-shared utility class, `GCTrimNative`, that takes care of trimming and GC-logging and houses the `NativeTrimmer` thread class. > - adds a regression test > > > ### Tests > > Tested older Glibc (2.31), and newer Glibc (2.35) (`mallinfo()` vs` mallinfo2()`), on Linux x64. > > The rest of the tests will be done by GHA and in our SAP nightlies. > > > ### Remarks > > #### How about other allocators? > > I have seen this retention problem mainly with the Glibc and the AIX libc. Muslc returns memory more eagerly to the OS. I also tested with jemalloc and found it also reclaims more aggressively, therefore I don't think MacOS or BSD are affected that much by retention either. > > #### Trim costs? > > Trim-native is a tradeoff between memory and performance. We pay > - The cost to do the trim depends on how much is trimmed. Time ranges on my machine between < 1ms for no-op trims, to ~800ms for 32GB trims. > - The cost for re-acquiring the memory, should the memory be needed again, is the second cost factor. > > #### Predicting malloc_trim effects? > > `ShenandoahUncommit` avoids uncommits if they are not necessary, thus avoiding work and gc log spamming. I liked that and tried to follow that example. Tried to devise a way to predict the effect trim could have based on allocator info from mallinfo(3). That was quite frustrating since the documentation was confusing and I had to do a lot of experimenting. In the end, I came up with a heuristic to prevent obviously pointless trim attempts; see `os::should_trim_native_heap()`. I am not completely happy with it. > > #### glibc.malloc.trim_threshold? > > glibc has a tunable that looks like it could influence the willingness of Glibc to return memory to the OS, the "trim_threshold". In practice, I could not get it to do anything useful. Regardless of the setting, it never seemed to influence the trimming behavior. Even if it would work, I'm not sure we'd want to use that, since by doing malloc_trim manually we can space out the trims as we see fit, instead of paying the trim price for free(3). > > > - [1] https://mail.openjdk.org/pipermail/hotspot-dev/2021-August/054323.html > - [2] https://bugs.openjdk.org/browse/JDK-8269345 @tstuefe Nice work! I also looked into memory usage recently, I found that `os::print_os_info()` is very usefully. I would like to purpose to add a diagnostics flag, e.g. `PrintProcessInfoAtExit` to capture some insights of the process, such as `RSS`, `Peak RSS`, `C-Heap` and `C-Heap Retained`. Here are some numbers I captured | | C-Heap Outstanding (K) | C-Heap Retained (K)| |--------------------|---------------: |---------------------: | |Compiler | 106387 | 271692 | |Sunflow | 103882 | 173929 | |Compress | 37794|11605| |CrytioAes | 37579|30580| |CryptoRsa |38318|73001| |CryptoSignVerify |37790|38769| |Derby |55389|186954| |MpegAudio |40280|71743| |ScimarkFFT.large |36698|8945| |ScimarkFFT.small |37071|10824| |ScimarkLU.large |38018|8529| |ScimarkLU.small |39198|8585| |ScimarkMonteCarlo |36946|6529| |ScimarkSOR.large |36648|8787| |ScimarkSOR.small |36569|9078| |ScimarkSparse.large |36745|9182| |ScimarkSparse.small |37253|8574| |Serial. |38652|127231| |Sunflow.test. | 45450|56657| |XmlTransform. |83116|289431| |XmlValidation |59883|59883| ? I captured the number at JVM exit, so it might not reflect runtime characters. But some number is quite interesting, e.g. `Derby` retained set is about x3 of outstanding set. ------------- PR: https://git.openjdk.org/jdk/pull/10085 From coleenp at openjdk.org Wed Aug 31 15:13:12 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 31 Aug 2022 15:13:12 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Wed, 31 Aug 2022 05:11:33 GMT, David Holmes wrote: >> I think you should add an assert that the `protection_domain.resolve()` never returns null, with a comment explaining why. > > I agree. In general if code is using WeakHandle's then I would expect to see null checks. I added the comment. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From rpressler at openjdk.org Wed Aug 31 16:31:25 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Wed, 31 Aug 2022 16:31:25 GMT Subject: RFR: 8292584: assert(cb != __null) failed: must be with -XX:-Inline [v5] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 07:01:57 GMT, Dean Long wrote: >> generate_Continuation_doYield_entry() creates an interpreter entry point, but jumps to a compiled stub, which needs to be walkable. The interpreter entry does not create an interpreter frame, so frame walking expects a compiled frame. Normally everything is OK, but if C1 does not inline the intrinsic and we get to the interpreter entry through the c2i adapter, then things can break if the c2i adapter padded the stack because of alignment. The easiest fix is to undo what the c2i adapter might have done. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > fix build failures Looks good AFAICT, but requires testing with the JTREG wrapper (i.e. loom tiers 1-5) ------------- Marked as reviewed by rpressler (Committer). PR: https://git.openjdk.org/jdk/pull/9974 From kbarrett at openjdk.org Wed Aug 31 17:38:08 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 31 Aug 2022 17:38:08 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> Message-ID: On Tue, 30 Aug 2022 20:00:56 GMT, Stefan Karlsson wrote: >> src/hotspot/share/utilities/globalDefinitions.hpp line 97: >> >>> 95: // _X - print as hexadecimal, without leading 0s: 0x12345 >>> 96: // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >>> 97: // _H - print as hexadecimal, without 0x prefix >> >> I think we don't have any of these "H" suffixed names. > > The patch has one usage of SIZE_FORMAT_H_W. We could of course just inline that usage, if you think that makes more sense. I don't see a use, or even a definition, of that name. There was the INTPTR_FORMAT_H_W that was moved to Shenandoah code. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From kbarrett at openjdk.org Wed Aug 31 17:45:13 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 31 Aug 2022 17:45:13 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v7] In-Reply-To: References: Message-ID: <6QW0UJ1KhGyteQ8GhHZw4AuXxlYL3elttK7EkX5niJE=.45546ebc-77cf-4a08-92fa-1ab2dc40f776@github.com> On Wed, 31 Aug 2022 12:30:10 GMT, Stefan Karlsson wrote: >> Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. >> >> This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. >> >> We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. >> >> I'd like to suggest that we use a convention to specify what we want. This is the current proposal: >> >> // Guide to the suffixes used in the format specifiers for integers: >> // - print the decimal value: 745565 >> // _X - print as hexadecimal, without leading 0s: 0x12345 >> // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >> // _H - print as hexadecimal, without 0x prefix >> // _W(w) - prints w sized string with the given value right >> // adjusted. Use -w to print left adjusted. >> // >> // Note that the PTR format specifiers print using 0x with leading zeros, >> // just like the _X_0 version for integers. >> >> >> The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. > > Stefan Karlsson 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 8292981_unify_integer_format_specifiers > - Remove _H variants > - Removed extraneous 0x > - Move INTPTR_FORMAT_H_W to Shenandoah > - Use PTR_FORMAT in AIX code > - Fix Shenandoah > - 8292981: Unify and restructure integer printing format specifiers I'm also okay with the naming as is for this change. We can revisit the names later if we want. Some of the pre-existing issues I noted probably should have followup RFEs. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/10042 From kbarrett at openjdk.org Wed Aug 31 17:45:14 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 31 Aug 2022 17:45:14 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v4] In-Reply-To: References: <8rbtvs_dqAo75FqCk1W4x_yawfYffys9yW8EGII1RA4=.90e3471e-7201-47c2-a47e-a77f5f40fc43@github.com> Message-ID: <0qeMQMdkTA7KGv-CnXsk-7ThLldrI317naLRhh5YWU0=.a2cb4421-e6e8-4bb2-867e-dc966ce941e1@github.com> On Wed, 31 Aug 2022 17:36:03 GMT, Kim Barrett wrote: >> The patch has one usage of SIZE_FORMAT_H_W. We could of course just inline that usage, if you think that makes more sense. > > I don't see a use, or even a definition, of that name. There was the INTPTR_FORMAT_H_W that was moved to Shenandoah code. Oh, it looks like you removed SIZE_FORMAT_H_W. I guess I missed it while it was there. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From amenkov at openjdk.org Wed Aug 31 21:28:24 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 31 Aug 2022 21:28:24 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v2] In-Reply-To: References: Message-ID: > The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) > > cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. > After successful RedefineClasses it should be reset. > The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: updated comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10032/files - new: https://git.openjdk.org/jdk/pull/10032/files/a3558d0a..d86ae7fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10032.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10032/head:pull/10032 PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Wed Aug 31 21:28:25 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 31 Aug 2022 21:28:25 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v2] In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 00:01:29 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> updated comments > > src/hotspot/share/classfile/klassFactory.cpp line 135: > >> 133: if (state != NULL) { >> 134: Klass* k = state->get_class_being_redefined(); >> 135: // use cached_class_file only for RetransformClasses > > More detailed comment would be nice to have here to explain in what scenario this change is needed. I updated a comment before the code block and removed this one ------------- PR: https://git.openjdk.org/jdk/pull/10032 From sspitsyn at openjdk.org Wed Aug 31 21:54:46 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 31 Aug 2022 21:54:46 GMT Subject: RFR: 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking Message-ID: The problem is that the following assert in the JvmtiExport::post_object_free is wrong: ` assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE), "checking");` Even though the condition was checked before, it can be changed later as it is racy by JVM TI design. It has to be replaced with the check: if (!env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { return; // the event type has been already disabled } In progress: mach5 nsk.jvmti and nsk.jdi test runs. ------------- Commit messages: - 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking Changes: https://git.openjdk.org/jdk/pull/10109/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10109&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293010 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10109.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10109/head:pull/10109 PR: https://git.openjdk.org/jdk/pull/10109 From vlivanov at openjdk.org Wed Aug 31 23:18:59 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 31 Aug 2022 23:18:59 GMT Subject: RFR: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp Message-ID: Introduce stubGenerator_x86_64.hpp and extract StubGenerator class declaration there. Testing: hs-tier1 - hs-tier4 ------------- Commit messages: - fix - stubGenerator_x86_64.hpp Changes: https://git.openjdk.org/jdk/pull/10111/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10111&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293188 Stats: 11125 lines in 2 files changed: 3954 ins; 3475 del; 3696 mod Patch: https://git.openjdk.org/jdk/pull/10111.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10111/head:pull/10111 PR: https://git.openjdk.org/jdk/pull/10111