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