On Wed, 9 Mar 2022 13:11:27 GMT, Roman Kennke wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [8eb453ba](https://github.com/openjdk/jdk/commit/8eb453baebe377697286f7eb32280ca9f1fd7775)
> from the [openjdk/jdk](https://git.openjdk.java.net/
On Wed, 9 Mar 2022 13:11:27 GMT, Roman Kennke wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [8eb453ba](https://github.com/openjdk/jdk/commit/8eb453baebe377697286f7eb32280ca9f1fd7775)
> from the [openjdk/jdk](https://git.openjdk.java.net/
Hi all,
This pull request contains a backport of commit
[8eb453ba](https://github.com/openjdk/jdk/commit/8eb453baebe377697286f7eb32280ca9f1fd7775)
from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repository.
The commit being backported was authored by Roman Kennke on 10 Dec
On Thu, 13 Jan 2022 12:19:03 GMT, Roman Kennke wrote:
>> Thread.java would benefit from a refactoring similar to JDK-8278065 to use
>> ClassValue instead of the somewhat problematic WeakClassKey mechanism.
>>
>> Testing:
>> - [x] tier1
>> - [x] tier2
On Wed, 12 Jan 2022 19:39:29 GMT, Roman Kennke wrote:
> Thread.java would benefit from a refactoring similar to JDK-8278065 to use
> ClassValue instead of the somewhat problematic WeakClassKey mechanism.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
This pull
On Thu, 13 Jan 2022 14:41:51 GMT, Roger Riggs wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove obsolete comment
>
> @AlanBateman has been doing a lot of work with j.l.Thre
On Wed, 26 Jan 2022 19:09:58 GMT, Alan Bateman wrote:
> I think this looks okay. It's only used when running with a SecurityManager
> so unlikely to be used in most deployments.
Thanks, Alan! Could you also 'approve' this PR?
Thanks, Roman
-
PR:
On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
On Fri, 14 Jan 2022 22:26:31 GMT, Aleksey Shipilev wrote:
> > One additional improvement would be to change r.get() == null to
> > r.refersTo(null) to check for cleared reference, that avoids reviving the
> > referent, e.g. in SATB GCs. I leave that up to you.
>
> I think that does not work,
On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote:
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
> issues with it:
> - The cache cannot disambiguate between cleared SoftReference and the
> accidental passing of `null` value; in that case, the retry
On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote:
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
> issues with it:
> - The cache cannot disambiguate between cleared SoftReference and the
> accidental passing of `null` value; in that case, the retry
On Thu, 13 Jan 2022 10:02:04 GMT, Andrey Turbanov wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove obsolete comment
>
> src/java.base/share/classes/java/lang/Thread.java line 1
> Thread.java would benefit from a refactoring similar to JDK-8278065 to use
> ClassValue instead of the somewhat problematic WeakClassKey mechanism.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
Roman Kennke has updated the pull request incrementally with o
Thread.java would benefit from a refactoring similar to JDK-8278065 to use
ClassValue instead of the somewhat problematic WeakClassKey mechanism.
Testing:
- [x] tier1
- [x] tier2
- [x] tier3
-
Commit messages:
- 8279917: Refactor subclassAudits in Thread to use ClassValue
On Wed, 12 Jan 2022 14:27:17 GMT, Roger Riggs wrote:
> I would have appreciated a chance to review the latest changes.
Oh, ok, I'm sorry. I will wait some more next time that I get into a similar
situation. I hope you're ok with the changes?
-
PR:
On Wed, 1 Dec 2021 14:45:23 GMT, Roman Kennke wrote:
> As a follow-up to #6375, this change refactors
> java.io.ObjectInputStream.Caches#subclassAudits and
> java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of
> SoftReference, similar to what we
On Wed, 12 Jan 2022 06:45:02 GMT, Peter Levart wrote:
> I think this looks good. Reviewed. Only a minor nit if you think it would be
> better, but not necessary if you don't. The following combo:
>
> ```
> Boolean result = Caches.subclassAudits.get(cl);
> assert result != null;
cs. Then we can now also remove the
> common machinery java.io.ObjectStreamClass#processQueue and
> java.io.ObjectStreamClass.WeakClassKey.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [ ] tier3
Roman Kennke has updated the pull request incrementally with two additio
On Fri, 10 Dec 2021 21:07:37 GMT, Roman Kennke wrote:
>> As a follow-up to #6375, this change refactors
>> java.io.ObjectInputStream.Caches#subclassAudits and
>> java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead
>> of SoftReference, similar
cs. Then we can now also remove the
> common machinery java.io.ObjectStreamClass#processQueue and
> java.io.ObjectStreamClass.WeakClassKey.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [ ] tier3
Roman Kennke has updated the pull request with a new target base due to a
cs. Then we can now also remove the
> common machinery java.io.ObjectStreamClass#processQueue and
> java.io.ObjectStreamClass.WeakClassKey.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [ ] tier3
Roman Kennke has updated the pull request with a new target base due to a
On Fri, 12 Nov 2021 21:43:42 GMT, Roman Kennke wrote:
> The caches in ObjectStreamClass basically map WeakReference to
> SoftReference, where the ObjectStreamClass also references
> the same Class. That means that the cache entry, and thus the class and its
> class-loader,
On Fri, 10 Dec 2021 14:44:07 GMT, Kevin Rushforth wrote:
> This is a P4 bug. If the priority is correct, it does not meet the criteria
> to get it into JDK 18 during RDP1, as indicated in [JEP
> 3](https://openjdk.java.net/jeps/3).
>
> If this is objectively a P3 bug, and really does need to
On Tue, 7 Dec 2021 10:42:50 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its cl
On Tue, 7 Dec 2021 06:23:22 GMT, Peter Levart wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix cast; add testcase to cover memory pressure
>
> test/jdk/java/io/ObjectStreamClass/Te
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request incrementally with one additional
commit
On Sat, 4 Dec 2021 08:47:03 GMT, Peter Levart wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary import
>
> src/java.base/share/classes/java/io/Cla
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request incrementally with one additional
commit si
On Thu, 2 Dec 2021 19:49:12 GMT, Roger Riggs wrote:
> Looks good.
Thank you!
I believe it makes sense to also use the ClassCache here, just as I did in
#6375. I'll change this PR accordingly tomorrow.
-
PR: https://git.openjdk.java.net/jdk/pull/6637
On Thu, 2 Dec 2021 16:14:18 GMT, Roger Riggs wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Implement ClassCache: reclaim entries under memory pressure
>
> ObjectStreamClass
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request incrementally with one additional
com
On Wed, 1 Dec 2021 21:09:14 GMT, Roger Riggs wrote:
> Without the use of SoftReference, memory pressure won't release any of the
> cached info. That seems to swing the other way from overly aggressively
> freeing memory with the WeakReference (and needing to recompute) as the
> change
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request incrementally with one additional
commit
As a follow-up to #6375, this change refactors
java.io.ObjectInputStream.Caches#subclassAudits and
java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of
SoftReference, similar to what we did in #6375 for
java.io.ObjectStreamClass.Caches#localDescs. Then we can now also
On Wed, 1 Dec 2021 10:49:54 GMT, Peter Levart wrote:
> ...I think that you could remove now obsolete
> java.io.ObjectStreamClass.EntryFuture nested class. It's not used any more.
Done.
> It would be nice to follow-up this patch with patches that make use of
> ClassValue also for:
>
> *
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request incrementally with one additional
commit si
On Mon, 15 Nov 2021 21:35:06 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its cl
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request with a new target base due to a merge
o
On Mon, 15 Nov 2021 21:35:06 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its cl
On Mon, 15 Nov 2021 21:35:06 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its cl
On Mon, 15 Nov 2021 19:30:54 GMT, Roger Riggs wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Use ForceGC instead of System.gc()
>> - Convert test to testng
>
>
SC's caches.
>
> The proposed change is to use WeakReference instead of SoftReference for the
> values in caches.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] tier3
> - [ ] tier4
Roman Kennke has updated the pull request incrementally with two additional
On Mon, 15 Nov 2021 18:01:04 GMT, Joe Darcy wrote:
> If the intent of this change is to alter the lifetimes of the objects in
> question in a meaningful way, I recommend a CSR for the behavioral
> compatibility impact.
It would be hard for application code to observe this change: before the
The caches in ObjectStreamClass basically map WeakReference to
SoftReference, where the ObjectStreamClass also references
the same Class. That means that the cache entry, and thus the class and its
class-loader, will not get reclaimed, unless the GC determines that memory
pressure is very
On Fri, 13 Aug 2021 14:41:54 GMT, Alan Bateman wrote:
> > Is this what you have been asking @mkarg in #4263 to do? Optimize
> > transferTo() only for FileInputStream? Would it interfere with #4263?
>
> #4263 is the input stream returned by Channels.newInputStream where the
> source may be a
On Thu, 12 Aug 2021 21:07:53 GMT, Brian Burkhalter wrote:
>> Please consider this request to add an override
>> `java.io.FileInputStream.transferTo(OutputStream)` with improved performance
>> if the parameter is a `FileOutputStream`.
>
> Brian Burkhalter has updated the pull request
On Mon, 18 Jan 2021 23:42:08 GMT, Kim Barrett wrote:
>> Please review this change which fixes the type of the private
>> Reference.discovered field. It was Reference, but that's wrong because
>> it can be any Reference object.
>>
>> I've changed it to Reference and let that flow through,
On Wed, 25 Nov 2020 23:35:14 GMT, Vladimir Kozlov wrote:
>> JDK-8188055 added the function Reference.refersTo. For performance, the
>> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
>> should be intrinsified by C2.
>>
>> Initial patch was prepared by @fisk.
>>
On Mon, 23 Nov 2020 19:18:05 GMT, Per Liden wrote:
>> test/hotspot/jtreg/gc/TestReferenceClearDuringReferenceProcessing.java line
>> 28:
>>
>>> 26: /* @test
>>> 27: * @bug 8256517
>>> 28: * @requires vm.gc.Z
>>
>> Please add | vm.gc.Shenandoah here.
>
> Note that for this test to be useful,
On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett wrote:
> Please review this change to Reference.clear() to address several issues.
>
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
>
> (JDK-8240696) For
On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett wrote:
> Please review this change to Reference.clear() to address several issues.
>
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
>
> (JDK-8240696) For
On Sun, 22 Nov 2020 22:15:20 GMT, Kim Barrett wrote:
> I didn't notice this before it was integrated.
>
> The test for inactive isn't right; rather than `next == this` it
> should be `next != null`. This becomes apparent once
> FinalizerHistogram is fixed to call getInactive() rather than
On Mon, 16 Nov 2020 17:29:20 GMT, Roman Kennke wrote:
> A follow-up to JDK-8256106, this is adding two asserts to check that the API
> is used as it should be, i.e. only on inactive FinalReferences. Also, in
> Finalizer, where getInactive() is used, there is a null-check. The GC must
A follow-up to JDK-8256106, this is adding two asserts to check that the API is
used as it should be, i.e. only on inactive FinalReferences. Also, in
Finalizer, where getInactive() is used, there is a null-check. The GC must
never clean the referent, and Java code doesn't clean it either, it
On Wed, 11 Nov 2020 18:13:30 GMT, Albert Mingkun Yang wrote:
> With `getInactive`, is the null check, `if (finalizee != null` still needed?
Good point! I don't think it is. The GC should not clean the referent before we
finalized it (or not at all), and no other code is clearing it either.
On Wed, 11 Nov 2020 18:19:01 GMT, Mandy Chung wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rename inactive-getter and improve javadocs
>
> src/java.base/share/classes/java/la
On Tue, 10 Nov 2020 09:37:29 GMT, Roman Kennke wrote:
> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee.
> Concurrent reference processing GCs like Shenandoah and ZGC would return NULL
> for unreachable referents, and thus would not call finalize() on them.
trong references.
>
> Testing:
> - [x] hotspot_gc_shenandoah
> - [x] tier1 +UseShenandoahGC +ShenandoahVerify
> - [x] tier2 +UseShenandoahGC +ShenandoahVerify
> - [x] tier1
> - [x] tier2
Roman Kennke has updated the pull request incrementally with one additional
commit
trong references.
>
> Testing:
> - [x] hotspot_gc_shenandoah
> - [x] tier1 +UseShenandoahGC +ShenandoahVerify
> - [x] tier2 +UseShenandoahGC +ShenandoahVerify
> - [x] tier1
> - [x] tier2
Roman Kennke has updated the pull request with a new target base due to a merge
or a re
Finalizer calls Reference.get() from the Finalizer to acquire the finalizee.
Concurrent reference processing GCs like Shenandoah and ZGC would return NULL
for unreachable referents, and thus would not call finalize() on them.
ZGC works around this by fixing the referent before enqueuing, so
On Thu, 2020-07-16 at 08:09 +0100, Alan Bateman wrote:
> On 15/07/2020 20:47, Roman Kennke wrote:
> > :
> > Why would it? Can you explain? (-ExplicitGCInvokesConcurrent is the
> > default for all GCs but Shenandoah, and has been that way forever.
> > Do
> > you
Hi Alan,
> On 15/07/2020 18:20, rken...@redhat.com wrote:
> > DirectBufferAllocTest is unreliable when running with
> > +ExplicitGCInvokesConcurrent, because allocating DBB spreads
> > System.gc() calls all over concurrent GC cycles. It becomes more
> > reliable when running with
That fix looks good to me.
Thanks!
Roman
> The revised webrev at [3] is confirmed by the submitter to fix the build.
>
> please review
>
> /Andy
>
> [3] http://cr.openjdk.java.net/~herrick/8235767/webrev.02/
>
> On 12/11/2019 9:49 AM, Andy Herrick wrote:
>> Please review simple jpackage fix
(adding core-libs-dev)
Ping?
> I just realized that this has still not been reviewed. Can I do anything
> to move forward?
>
> Thanks,
> Roman
>
>> I added one extra verification to the JAXP based properties parser to
>> verify that no extra internal DTD is being supplied. As far as I can
>>
>> Any other comments on:
>> "* Runs the garbage collector in the Java Virtual Machine.
>> *
>> * Calling this method suggests that the Java Virtual Machine
>> * expend effort toward recycling unused objects in order to
>> * make the memory they currently occupy available for reuse
>> * by the
I have verified that the program that failed before doesn't appear to
fail anymore.
The patch looks good to me.
Thanks!
Roman
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8212178
>
> See the details in the bug. We are hitting this race when Shenandoah is
> running in aggressive mode
>
Hi Christoph & Magnus, thanks for reviewing!
Am 27.09.18 um 08:22 schrieb Langer, Christoph:
> Hi Roman,
>
> this looks good to me. +1
>
> Best regards
> Christoph
>
>> -Original Message-
>> From: build-dev On Behalf Of
>> Roman Kennke
Ping core-libs?
Roman
Am 25.09.18 um 11:06 schrieb Magnus Ihse Bursie:
>
>> 25 sep. 2018 kl. 10:21 skrev Roman Kennke :
>>
>> Not sure this is the correct list. Please redirect as appropriate.
>
> I believe core-libs is the appropriate place. Cc:d.
>
>
.
**Roman
-Original Message-
From: Chris Hegarty [mailto:chris.hega...@oracle.com]
Sent: 22 December 2010 17:35
To: Roman Kennke
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Potential memory leak in java.util.logging.Level
On 12/22/10 02:36 PM, Roman Kennke wrote:
Hello,
I believe
Hello,
I believe java.util.logging.Level is potentially memory leaking. This can
happen if an application defines its own subclass of Level and is loaded by its
own classloader. Level's constructor adds a reference to the new instance of
the subclass to its 'known' ArrayList (which is a static
Hi Mario,
According to the specs, malloc may return either a valid pointer that
can be passed to free, or NULL, while generally NULL is considered to be
a failure. Linux and Solaris, albeit non specifying it, return always a
valid pointer, as far as I know
I think NULL is returned in
Hi,
there are some classes in the jdk/share tree, that seem to be Solaris
specific. I suggest moving them to the jdk/solaris tree instead. Or am I
wrong here?
/Roman
--
http://kennke.org/blog/
# HG changeset patch
# User Roman Kennke [EMAIL PROTECTED]
# Date 1201293270 -3600
# Node ID
Hi there,
snip
Currently, there exist much better solutions than BigDecimal,
unfortunately not from the Java space. For instance GMP
( http://gmplib.org/) is considered as one of the state of the art
libraries in the area of precision arithmetics. And several libraries
extent GMP such as
Hi list,
The PlainSocketImpl family of classes have a method socketGetOption1(),
which is required by the AbstractPlainSocketImpl class, and implemented
by the subclasses, but apparently never used. There isn't even a native
implementation for the native method in PlainSocketImpl. Could this
This fixes a problem with sliced StringCharBuffers. See:
http://bugs.sun.com/view_bug.do?bug_id=6546113
Feel free to integrate this in the repository.
Cheers, Roman
--
http://kennke.org/blog/
I definitely need this new Evolution thingy. Forgot the actual
attachement..
Am Donnerstag, den 27.09.2007, 20:50 +0200 schrieb Roman Kennke:
This fixes a problem with sliced StringCharBuffers. See:
http://bugs.sun.com/view_bug.do?bug_id=6546113
Feel free to integrate
76 matches
Mail list logo
