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/jdk) repository.
>
> The commit
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/jdk) repository.
>
> The commit
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 2021
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 class-loader, will not get recl
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 g
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 class-loader, will not get recl
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 class-loader, will not get recl
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/TestOSCClassLoaderLeak.java line
> 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
On Mon, 6 Dec 2021 12:12:44 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, will not get recl
On Mon, 6 Dec 2021 12:12:44 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, will not get recl
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/ClassCache.java line 63:
>
>> 61: protect
> 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
On Thu, 2 Dec 2021 16:22:02 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, will not get recl
On Thu, 2 Dec 2021 14:24:06 GMT, Roman Kennke wrote:
>> src/java.base/share/classes/java/io/ObjectStreamClass.java line 2133:
>>
>>> 2131: if (oldReflector != null) {
>>> 2132: reflector = oldReflector;
>>> 2133: }
>>
>> Map.computeIfAbsent(key, () -> new
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 may have an unnecesary import of `SoftR
> 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
On Thu, 2 Dec 2021 14:30:07 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, will not get recl
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 original
> 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
On Wed, 1 Dec 2021 12:18:05 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, will not get recl
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:
>
> * j
> 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
On Tue, 30 Nov 2021 11:25:48 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, will not get rec
On Tue, 30 Nov 2021 11:25:48 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, will not get rec
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 class-loader, will not get rec
> 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
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 class-loader, will not get rec
On Mon, 29 Nov 2021 13:47:19 GMT, Roman Kennke wrote:
> I don't quite understand this: If the Class object is still reachable by the
> app,
1. a weak reference would not get cleared and
2. the Class's ClassLoader would not get unloaded.
...but the ObjectStreamClass instance could still get GC-
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 class-loader, will not get rec
On Mon, 15 Nov 2021 19:10:17 GMT, Roman Kennke 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:
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 class-loader, will not get rec
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
>
> test/jdk/java/io/ObjectStreamClass/TestOSCClassLoa
> 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
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, will not get reclaim
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
c
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, will not get reclaim
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 high.
38 matches
Mail list logo
