Re: RFR: 8326152: Bad copyright header in test/jdk/java/util/zip/DeflaterDictionaryTests.java
On Mon, 19 Feb 2024 09:34:12 GMT, Jaikiran Pai wrote: > Can I get a review of this change which fixes the copyright header on > `DeflaterDictionaryTests.java`? Ship it. - Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17911#pullrequestreview-1888008996
Re: OpenJDK 17: Loitering AbstractQueuedSynchronizer$ConditionNode instances
Hi, since this looks like a suggestion for a change to the libraries similar to the mentioned JDK-6805775, and not actually GC, cc'ing the core-libs-dev mailing list. Hth, Thomas On 07.02.24 15:20, Frank Kretschmer wrote: Hi Java GC-experts, I'm facing an interesting G1 garbage collector observation in OpenJDK 17.0.9+9, which I would like to share with you. My application runs many asynchronous tasks in a fixed thread pool, utilizing its standard LinkedBlockingQueue. Usually, it generates just a little garbage, but from time to time, I observed that the survivor spaces grow unexpectedly, and minor collection times increase. This being the case, many java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode instances can be found on the heap. In fact, the whole heap (rank 1 as shown in jmap) was filled up with ConditionNode instances after a while. After some tests, I figured out that G1 seems to be able to collect “dead” ConditionNode instances during minor collections only if no formerly alive ConditionNode instances were promoted to the old generation and died there. To illustrate that, I've attached a “G1LoiteringConditionNodes” class that can be run for demo purposes, e.g. under Linux with OpenJDK 17.0.9+9 (VM options see comments within the class), and its gc-log output. It shows that during the first two minutes, everything is fine, but after a promotion to the old generation, survivors grow and minor pause time increase from 3 to 10ms. For me, it looks like an issue similar to https://bugs.openjdk.org/browse/JDK-6805775 “LinkedBlockingQueue Nodes should unlink themselves before becoming garbage”, which was fixed in OpenJDK 7. What’s your opinion about that? Wouldn’t it be worth to enable G1 to collect those AbstractQueuedSynchronizer$ConditionNode instances during minor collections, as it is done for LinkedBlockingQueue Nodes? Best regards Frank Kretschmer, Java Realtime Application Developer
Re: RFR: 8323508: Remove TestGCLockerWithShenandoah.java line from TEST.groups
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote: > TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups > file still has a reference to it. This causes problems in our CI pipeline. lgtm. - Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17344#pullrequestreview-1813156136
Re: RFR: 8321130: Microbenchmarks do not build any more after 8254693 on 32 bit platforms
On Thu, 30 Nov 2023 20:59:01 GMT, Jorn Vernee wrote: > Need to use `jlong_to_ptr` instead of raw cast. > > I've also fixed another latent issue in `CLayouts` where we were initializing > `C_LONG_LONG` with the `long` layout. This was resulting in a class cast > exception when running the XorTest benchmark. The size of `long` on Linux x86 > 32-bits is 4 bytes, so the returned layout has type `ValueLayout.OfInt` which > we then try to cast to `ValueLayout.OfLong`, resulting in a CCE. This would > also be an issue on Windows. > > Testing: running XorTest benchmark on linux-x86 and windows-x64. Marked as reviewed by tschatzl (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/16913#pullrequestreview-1759654945
Re: RFR: JDK-8311026: Some G1 specific tests do not set -XX:+UseG1GC
On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken wrote: > Most G1 tests set -XX:+UseG1GC, but a few (e.g. > gc/g1/TestVerificationInConcurrentCycle.java) miss that. > This is usually just fine and no problem because G1 is the default anyway. > However in some cases, where a custom JVM changes the default GC, those tests > start to fail which is not really necessary. Marked as reviewed by tschatzl (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14722#pullrequestreview-1507020443
Re: Testing no memory leak occurs via references
Hi, On 03.03.23 19:02, Aleksei Ivanov wrote: > Hello, > > In clientlibs, there's occasionally a need to verify an object isn't > leaked. For this purpose, WeakReference or PhantomReference is used. > > Then, we need to make the reference object be cleared, so a GC cycle > need to be triggered. The common approach is generating > OutOfMemoryError, catching it and verifying whether the reference is > cleared. > > Some tests use a utility method regtesthelpers/Util.generateOOME [1]. > > For example, these tests follow the above approach: > https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/border/TestTitledBorderLeak.java > https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java > > > The AwtListGarbageCollectionTest.java test started to fail pretty often > in the end of January 2023. > > I followed a piece of advice provided in a JBS comment for JDK-8300727 > [2] and replaced generating OOME with a simple call to System.gc() along > with adding a loop for re-trying. > > The specification for System.gc() [3] mentions that this call can be > ignored, which started a discussion in the PR #12594 [4] that > System.gc() should not be used, at the very least without generating > OOME in addition to invoking System.gc(). > > At the same time, many tests for Reference objects, such as > ReferenceEnqueue.java [5] and PhantomReferentClearing.java [6], rely > solely on System.gc. > > > What would be your recommendation? Are there best practices in core-libs > and hotspot for testing for memory leaks that clientlibs should follow? > For tests, the Whitebox methods allow you to specify the exact GC you want to have with a guarantee that it will be executed (in addition to potentially others caused naturally by the application!), i.e. minor/major gc, and specific to collectors, start concurrent gcs etc. E.g. test/hotspot/jtreg/gc/whitebox/TestWBGC.java gives an example how to execute young gcs. It may not be a comprehensive API to test all kinds of GCs, but it fits the use cases we need so far. I recommend to not use OOME for anything unless in extremely specific situations (test OOME is triggered or something). At/after OOME the VM is in a very precarious state that can give unexpected VM bailouts. Thanks, Thomas
