Integrated: 8284435: Add dedicated filler objects for known dead Java heap areas

On Fri, 8 Apr 2022 08:13:33 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that adds dedicated filler objects to > the VM? > > Currently, when formatting areas of dead objects all gcs use instances of > j.l.Object and int-arrays. >

Re: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v3]

On Mon, 11 Apr 2022 14:55:32 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that adds dedicated filler objects to >> the VM? >> >> Currently, when formatting areas of dead objects all gcs use instances of >>

Re: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v3]

On Fri, 29 Apr 2022 16:45:01 GMT, Ioi Lam wrote: >> Thomas Schatzl has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix test > > The latest version looks good to me. Thanks @iklam @walulyai for your rev

Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]

On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which >> JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the >> loom repo. >> >> Most of the new mechanisms in

Re: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v3]

On Mon, 11 Apr 2022 21:51:32 GMT, David Holmes wrote: > Do you really need to define a real `FillerObject.java` class? Can't you use > an internal-only variant of a hidden class to represent this? I am not sure I understand this request, but of course I am open to try different approaches. An

Re: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v3]

for that, looking at other internal > symbols/klasses, but I'm not sure this adheres to naming guidelines. > > Thanks go to @iklam for helping out with the change. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional comm

Re: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v2]

On Fri, 8 Apr 2022 16:45:54 GMT, Ioi Lam wrote: >> Thomas Schatzl has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - iklam review >> - Test case > > src/hotspot/share/classfile/systemDictio

Re: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v2]

for that, looking at other internal > symbols/klasses, but I'm not sure this adheres to naming guidelines. > > Thanks go to @iklam for helping out with the change. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with two additional comm

RFR: 8284435: Add dedicated filler objects for known dead Java heap areas

Hi all, can I have reviews for this change that adds dedicated filler objects to the VM? Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays. This has the drawback of not being easily able to discern whether a given object is actually dead

Re: RFR: 8277494: [BACKOUT] JDK-8276150 Quarantined jpackage apps are labeled as "damaged"

On Fri, 19 Nov 2021 20:57:46 GMT, Daniel D. Daugherty wrote: > This reverts commit 936f7ff49ed86adb74bb1ff10d93cb3d7f7d70a0. > > So far we've had 3 failed Tier2 job sets in a row. My Mach5 Tier2 of this > [BACKOUT] has > passed the macosx-aarch64 test task that was failing before. Marked as

Re: RFR: 8275262: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE

On Thu, 14 Oct 2021 06:37:19 GMT, Nick Gasson wrote: > This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE" > which caused some unknown failures in Oracle's CI. Lgtm. - Marked as reviewed by tschatzl (Reviewer). PR:

Re: RFR: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible [v4]

On Tue, 31 Aug 2021 20:04:23 GMT, Сергей Цыпанов wrote: >> Just a very tiny clean-up. >> >> There are some places in JDK code base where we call >> `Enum.class.getEnumConstants()` to get all the values of the referenced >> `enum`. This is excessive, less-readable and slower than just calling

Re: RFR: 8271396: Spelling errors

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg wrote: > This PR fixes the following spelling errors: > > choosen -> chosen > commad -> command > hiearchy -> hierarchy > leagacy -> legacy > minium -> minimum > subsytem -> subsystem > unamed -> unnamed Lgtm. -

Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]

On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung wrote: >> This spec clarification is a follow-up to >> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) >> w.r.t. reference

Re: [jdk17] RFR: 8269534: Remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt

On Mon, 28 Jun 2021 17:05:49 GMT, Daniel D. Daugherty wrote: > A trivial fix to remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java > from ProblemList.txt Lgtm and trivial. - Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/164

Re: RFR: 8254598: StringDedupTable should use OopStorage [v2]

On Fri, 7 May 2021 08:28:43 GMT, Kim Barrett wrote: >> Please review this change to the String Deduplication facility. It is being >> changed to use OopStorage to hold weak references to relevant objects, >> rather than bespoke data structures requiring dedicated processing phases by >>

Re: RFR: 8254598: StringDedupTable should use OopStorage

On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett wrote: > Please review this change to the String Deduplication facility. It is being > changed to use OopStorage to hold weak references to relevant objects, > rather than bespoke data structures requiring dedicated processing phases by > supporting

Re: RFR: 8257876: Avoid Reference.isEnqueued in tests [v2]

On Thu, 10 Dec 2020 08:56:25 GMT, Kim Barrett wrote: >> I understand that the test code previously just forwarded the >> `InterruptedException` if it happened in the `Thread.sleep()` call too. So >> this may only be an exiting issue and please ignore this comment. >> Not catching

Re: RFR: 8257876: Avoid Reference.isEnqueued in tests [v2]

On Thu, 10 Dec 2020 09:01:54 GMT, Kim Barrett wrote: >> Please review this change that eliminates the use of Reference.isEnqueued by >> tests. There were three tests using it: >> >> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java >>

Re: RFR: 8257876: Avoid Reference.isEnqueued in tests

On Wed, 9 Dec 2020 13:23:47 GMT, Thomas Schatzl wrote: >> Please review this change that eliminates the use of Reference.isEnqueued by >> tests. There were three tests using it: >> >> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java >> vmTestb

Re: RFR: 8257876: Avoid Reference.isEnqueued in tests

On Tue, 8 Dec 2020 09:52:51 GMT, Kim Barrett wrote: > Please review this change that eliminates the use of Reference.isEnqueued by > tests. There were three tests using it: > > vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java > vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java >

Re: RFR: 8257876: Avoid Reference.isEnqueued in tests

On Tue, 8 Dec 2020 17:30:11 GMT, Mandy Chung wrote: >> Please review this change that eliminates the use of Reference.isEnqueued by >> tests. There were three tests using it: >> >> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java >>

Re: RFR: 8253583: java/util/StringJoiner tests failing on 32-bit VMs after JDK-8246697

On Thu, 24 Sep 2020 10:02:13 GMT, Aleksey Shipilev wrote: >> Lgtm. > > Trivial, right? Trivial. - PR: https://git.openjdk.java.net/jdk/pull/331

Re: RFR: 8253583: java/util/StringJoiner tests failing on 32-bit VMs after JDK-8246697

On Thu, 24 Sep 2020 08:35:24 GMT, Aleksey Shipilev wrote: > JDK-8246697 added -Xmx4g to test configurations. 32-bit VMs cannot do it. > @requires tests the OS RAM size, but you can > easily have the x86_32 host with more than 4G ram, yet JVM would fail to > acquire that heap size. Need to

Re: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)

Hi, I looked a bit at the allocations themselves, but first answering questions. On 15.07.20 15:25, David Holmes wrote: > On 15/07/2020 10:18 pm, Jim Laskey wrote: >> Thomas explained: That large objects are never moved (outstanding >> issue) So, it's possible to fragment the -Xmx4g such

Re: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)

Hi, On 15.07.20 15:35, Jim Laskey wrote: Try this: - You have a 4G heap. - You allocate some stuff, say 1 byte. - You allocate a 2G object - so there is only 2G - 1, left. Not enough space for another 2G object. - But you do allocate 1 byte. - You have 1 byte, 2G and 1 byte. - You free the

Re: RFR: 8188055: (ref) Add Reference.refersTo predicate

Hi, On 08.04.20 02:25, Kim Barrett wrote: [Note review on both core-libs and hotspot-gc-dev lists; try not to lose either when replying.] Please review a new function: java.lang.ref.Reference.refersTo. [...] CR: https://bugs.openjdk.java.net/browse/JDK-8188055

Re: RFR: Small cleanups in java.lang.ref

Hi Martin, On Fri, 2018-05-18 at 07:47 -0700, Martin Buchholz wrote: > > > On Fri, May 18, 2018 at 3:26 AM, Thomas Schatzl <thomas.schatzl@oracl > e.com> wrote: > > Hi, > > > > On Wed, 2018-05-16 at 18:31 -0700, Martin Buchholz wrote: > > >

Re: RFR: Small cleanups in java.lang.ref

Hi, On Wed, 2018-05-16 at 18:31 -0700, Martin Buchholz wrote: > I've been confused by NULL vs null for years. > > 8203327: Small cleanups in java.lang.ref > http://cr.openjdk.java.net/~martin/webrevs/jdk/Reference-cleanup/ > https://bugs.openjdk.java.net/browse/JDK-8203327 JDK-8203028 which

Re: GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and java.util.zip.DeflaterOutputStream

Hi, On Fri, 2018-03-16 at 17:19 +, Ian Rogers wrote: > Thanks Paul, very interesting. > > On Fri, Mar 16, 2018 at 9:21 AM Paul Sandoz > wrote: > > Hi Ian, Thomas, > > > > [...] > > (This is also something we need to consider if we modify buffers to > > support

Re: GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and java.util.zip.DeflaterOutputStream

Hi, On Thu, 2018-03-15 at 01:00 +, Ian Rogers wrote: > An old data point on how large a critical region should be comes from > java.nio.Bits. In JDK 9 the code migrated into unsafe, but in JDK 8 > the copies within a critical region were bound at most copying 1MB: >

Re: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM)

Hi, On Wed, 2018-02-14 at 13:45 -0800, sangheon.kim wrote: > Hi all, > > Could I have some reviews for CMM removal? > This is closed CR but some public codes also need small > modifications. > This CR is for removing stuff related to an Oracle JDK > module/package. > Changes are just removing

Re: RFR(s): 8191859: SoftReference clock/timestamp should be declared volatile

Hi, On Fri, 2017-11-24 at 14:13 +0100, Per Liden wrote: > The clock and timestamp fields in SoftReference should be declared > volatile. These fields are read or updated by the VM, (possibly) > concurrently with the execution of Java threads. > > To be more specific, the timestamp field is

Re: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with RuntimeException: Error: poll() returned null; expected ref object

Hi Kim, On Wed, 2015-07-29 at 03:57 -0400, Kim Barrett wrote: Please review this fix of a race condition in j.l.r.Reference/ReferenceQueue. See comments in the bug report for a description of the race. The race is being fixed by reordering a pair of volatile assignments. CR:

Re: Another take on Finalization

Hi, On Sun, 2015-06-07 at 10:46 +0200, Peter Levart wrote: Hi, On 06/05/2015 11:11 PM, Jonathan Payne wrote: My problem was that finalization was not being run at all with the G1 collector. Not at all. That would have been fine with me because none of the existing objects in the Finalizer

[Fwd: Missing merge for 8014890: Reference queues may return more entries than expected]

Hi all, could somebody take care of the missing merge for the fix below? Thanks, Thomas Forwarded Message From: Thomas Schatzl thomas.scha...@oracle.com To: mandy.ch...@oracle.com Subject: Missing merge for 8014890: Reference queues may return more entries than expected

Re: [Fwd: Missing merge for 8014890: Reference queues may return more entries than expected]

Hi, On Wed, 2013-08-14 at 10:43 +0100, Alan Bateman wrote: Mandy is just back from vacation and might not have got to your mail yet. However it's not clear to me that there is an actual problem as it looks like you've just ended up with two heads, maybe a hg fetch when you had changes

Re: RFR (XS): 8014890 : Reference queues may return more entries than expected

Hi, On Fri, 2013-07-12 at 19:22 +0800, Mandy Chung wrote: Hi Thomas, On 7/1/2013 7:51 PM, Thomas Schatzl wrote: I changed this in http://cr.openjdk.java.net/~tschatzl/8014890/webrev.refactor to that version now, using a temporary variable that stores r.queue before the checks

Re: RFR (XS): 8014890 : Reference queues may return more entries than expected

Hi David, On Mon, 2013-07-01 at 17:51 +1000, David Holmes wrote: Well you can ignore what I wrote below - sorry. Somehow I got it in my head that multiple enqueue's were intended/supported when of course they are not. :( So the proposed fix is okay - though I'd simplify the comment to

Re: RFR (XS): 8014890 : Reference queues may return more entries than expected

Hi all, On Mon, 2013-07-01 at 15:44 +0400, Aleksey Shipilev wrote: On 07/01/2013 03:37 PM, David Holmes wrote: On 1/07/2013 8:14 PM, Aleksey Shipilev wrote: The same thou shalt not do multiple volatile reads applies to (r.queue == NULL) || (r.queue == ENQUEUED) now. Doesn't that just

Re: RFR (XS): 8014890 : Reference queues may return more entries than expected

Hi, On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote: Hi Thomas, On 19/06/2013 7:08 AM, Thomas Schatzl wrote: Hi all, can I have reviews for the following change? It happens if multiple threads are enqueuing and dequeuing reference objects into a reference queue

Re: RFR (XS): 8014890 : Reference queues may return more entries than expected

Hi, On Tue, 2013-06-18 at 15:53 -0700, Mandy Chung wrote: Hi Thomas, Thanks for the detailed analysis. http://cr.openjdk.java.net/~tschatzl/8014890/webrev/ The fix looks good. I was able to reproduce the failure with the test case in the bug report running with jdk8 b94 fastdebug

Re: RFR (XS): 8014890 : Reference queues may return more entries than expected

Hi again, some correction... On Wed, 2013-06-19 at 09:17 +0200, Thomas Schatzl wrote: Hi, On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote: Hi Thomas, On 19/06/2013 7:08 AM, Thomas Schatzl wrote: Hi all, can I have reviews for the following change? It happens

Re: RFR (XS): 8014890 : Reference queues may return more entries than expected

Hi, one more note :) On Wed, 2013-06-19 at 09:28 +0200, Thomas Schatzl wrote: Hi again, some correction... On Wed, 2013-06-19 at 09:17 +0200, Thomas Schatzl wrote: Hi, On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote: Hi Thomas, On 19/06/2013 7:08 AM, Thomas

Re: RFR (XS): 8014890 : Reference queues may return more entries than expected

Hi Peter, On Wed, 2013-06-19 at 11:05 +0200, Peter Levart wrote: On 06/19/2013 09:17 AM, Thomas Schatzl wrote: Hi, On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote: Hi Thomas, On 19/06/2013 7:08 AM, Thomas Schatzl wrote: Hi all, can I have reviews for the following

Re: RFR (XS): 8014890 : Reference queues may return more entries than expected

Hi, On Wed, 2013-06-19 at 09:25 +0200, Thomas Schatzl wrote: Hi, On Tue, 2013-06-18 at 15:53 -0700, Mandy Chung wrote: Hi Thomas, Thanks for the detailed analysis. http://cr.openjdk.java.net/~tschatzl/8014890/webrev/ The fix looks good. I was able to reproduce the failure

Re: RFR (XS): 8014890 : Reference queues may return more entries than expected

Hi, On Wed, 2013-06-19 at 17:56 +0400, Aleksey Shipilev wrote: On 06/19/2013 04:05 PM, David Holmes wrote: I think I'm going to need a lot more time to understand this issue completely. The synchronization being used seems complex and somewhat ill-defined, and also inadequate. I'm not

RFR (XS): 8014890 : Reference queues may return more entries than expected

Hi all, can I have reviews for the following change? It happens if multiple threads are enqueuing and dequeuing reference objects into a reference queue, that Reference objects may be enqueued at multiple times. This is because when java.lang.ref.ReferenceQueue.poll() returns and inactivates

Re: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

On 17/05/2013 5:56 PM, Thomas Schatzl wrote: On Fri, 2013-05-17 at 10:47 +1000, David Holmes wrote: On 16/05/2013 8:44 PM, Thomas Schatzl wrote: On Mon, 2013-05-13 at 13:55 +0200, Thomas Schatzl wrote: I updated the test program and the patch in java.lang.ref.Reference accordingly

Re: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi, On Fri, 2013-05-24 at 09:09 +0100, Alan Bateman wrote: On 24/05/2013 08:20, Thomas Schatzl wrote: Hi all, On Fri, 2013-05-24 at 14:30 +1000, David Holmes wrote: Thomas, Are we still waiting for a second core-libs reviewer on this? Yes. Would some additional core-libs reviewer

Re: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi all, On Mon, 2013-05-13 at 13:55 +0200, Thomas Schatzl wrote: Hi all, I updated the test program and the patch in java.lang.ref.Reference accordingly. As for the problem of reproducibility, in my tests I had a 100% reproduction rate with the previous version of the test. However

Re: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi, On Sat, 2013-05-11 at 09:45 +1000, David Holmes wrote: On 11/05/2013 6:53 AM, Dean Long wrote: On 5/10/2013 1:22 PM, Peter Levart wrote: On 05/10/2013 10:08 PM, Peter Levart wrote: On 05/10/2013 08:10 PM, Dean Long wrote: If you really want to bullet-proof ReferenceHandler (and

Re: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi all, On Fri, 2013-05-10 at 12:52 +0200, Peter Levart wrote: Hi David, Thomas, I think I understand you now, David. You want to minimize the possibility of vacuously passing the test. So here's my attempt at that: public class OOMEInReferenceHandler { static Object[] fillHeap()

Re: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi, please review the latest webrev for this patch that is available at http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ As mentioned, it incorporates the fix and reproducer from Peter Levart. Bugs.sun.com: http://bugs.sun.com/view_bug.do?bug_id=7038914 JIRA:

Re: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi all, On Tue, 2013-05-07 at 12:31 +1000, David Holmes wrote: Catching ThreadDeath is futile. If someone is invoking stop() then you can encounter the ThreadDeath anywhere and it is impossible to write completely robust code in the face of such an async exception. So please let's not even

Re: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi, On Tue, 2013-05-07 at 15:12 +0200, Peter Levart wrote: On 05/07/2013 09:51 AM, Thomas Schatzl wrote: Hi all, On Tue, 2013-05-07 at 12:31 +1000, David Holmes wrote: Catching ThreadDeath is futile. If someone is invoking stop() then you can encounter the ThreadDeath anywhere

Re: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi, On Tue, 2013-05-07 at 16:10 +0200, Peter Levart wrote: On 05/07/2013 03:26 PM, Thomas Schatzl wrote: Hi, There is a message emitted by the VM reading java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread Reference Handler that is sufficient to detect

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi, On Sat, 2013-05-04 at 21:23 +0200, Peter Levart wrote: On 05/04/2013 07:38 PM, Vitaly Davidovich wrote: Oops, that was my mistake - I thought the lock here was a j.u.c.Lock which of course doesn't even make sense given we're talking about ObjectMonitor. So disregard that bit.

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi, Hi Tomas, I don't know if this is the case here, but what if the ReferenceHandler thread is interrupted while wait()-ing and the construction of InterruptedException triggers OOME? I am sure this is the case - previously I thought InterruptedException is a preallocated exception like

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi, On Tue, 2013-04-30 at 16:44 +0100, Alan Bateman wrote: On 30/04/2013 15:57, Thomas Schatzl wrote: Hi all, the webrev at http://cr.openjdk.java.net/~tschatzl/7038914/webrev/ presents a first stab at the CR 7038914: VM could throw uncaught OOME in ReferenceHandler thread

(Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi all, the webrev at http://cr.openjdk.java.net/~tschatzl/7038914/webrev/ presents a first stab at the CR 7038914: VM could throw uncaught OOME in ReferenceHandler thread. The problem is that under very heavy memory pressure, there is the reference handler throws an exception with the message