Reducing Classloader's parallelLockMap memory consumption proposal
Alan Bateman
alan.bateman at oracle.com
Wed May 21 14:18:04 UTC 2025
On 20/05/2025 03:42, Dmytro Ukhlov wrote:
> Hello!
>
> I created PR is scope of jenkins-core project:
> https://github.com/jenkinsci/jenkins/pull/10659
> Jira ticket: https://issues.jenkins.io/browse/JENKINS-75675
>
> In this PR i propped to override
> protected Object getClassLoadingLock(String className)
> method and use weak references for lock objects
>
> Jenkins is a plugable platform, each plugin has its own class loader
> and its parallelLockMap may consume 10mb of RAM. As a result it might
> have 2gb overhead if ~200 plugins installed.
>
> Jenkins maintainers ask me to consider making this improvement in base
This is an issue for "parallel capable" class loaders, esp. those that
don't directly delegate. I don't know what topology is used in the
Jenkins plugin class loaders and whether these class loader need to
parallel capable.
Expunging entries isn't really feasible, at least not without changing
the spec.
JDK-8005233 [1] has a write-up from David Holmes on this topic and a
prototype for "fully concurrent" class loaders. This work has been
parked for several years. Maybe some day it will get dusted off and a
JEP drafted (due to the significance).
-Alan
[1] https://bugs.openjdk.org/browse/JDK-8005233
More information about the core-libs-dev
mailing list