ByteBuddy TypeCache stale entries should be cleared to avoid (weak) references to application classloader

Description

On WildFly, I deployed a small application four times (a.jar, b.jar, c.jar, d.jar), which I am attaching as 2lc.jar. I undeployed the four copies of the application and looked at the WildFly memory via Eclipse Memory Analyzer and could see that four copies of the application classloader was still in memory.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Class Name | Shallow Heap | Retained Heap -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- org.jboss.modules.ModuleClassLoader @ 0xe122cb40 | 88 | 86,048 '- referent net.bytebuddy.TypeCache$StorageKey @ 0xe1b5f6b0 | 32 | 32 '- key java.util.concurrent.ConcurrentHashMap$Node @ 0xe1b5f690 | 32 | 520 '- [9] java.util.concurrent.ConcurrentHashMap$Node[16] @ 0xe1b5f640 | 80 | 2,328 '- table java.util.concurrent.ConcurrentHashMap @ 0xe1b5f600 | 64 | 2,392 '- cache net.bytebuddy.TypeCache$WithInlineExpunction @ 0xe1b5f5c8 | 40 | 2,448 '- CACHE class org.hibernate.proxy.pojo.bytebuddy.ByteBuddyProxyFactory @ 0xe1b5f558 | 8 | 2,472 '- [1559] java.lang.Object[2560] @ 0xe1b14fc8 | 10,256 | 1,400,648 '- elementData java.util.Vector @ 0xe05ce338 | 32 | 1,400,680 '- classes org.jboss.modules.ModuleClassLoader @ 0xe05ce1d8 | 88 | 1,508,904 |- loader java.util.ServiceLoader @ 0xfe8cd370 Native Stack | 32 | 1,368 |- loader java.util.ServiceLoader @ 0xfe8cd6d0 Native Stack | 32 | 1,368 |- <classloader> class org.hibernate.engine.transaction.jta.platform.internal.JBossAppServerJtaPlatform @ 0xe1299998 | 16 | 16 |- loader java.util.ServiceLoader$LazyIterator @ 0xfe8cd918 | 40 | 960 |- loader java.util.ServiceLoader$LazyIterator @ 0xfe968570 | 40 | 960 |- <classloader> class org.hibernate.engine.transaction.jta.platform.internal.TransactionManagerBasedSynchronizationStrategy @ 0xe193e9e0 | 0 | 0 |- <classloader> class org.hibernate.engine.transaction.jta.platform.internal.SynchronizationRegistryBasedSynchronizationStrategy @ 0xe1961a28| 0 | 0 |- <classloader> class org.hibernate.boot.registry.internal.StandardServiceRegistryImpl @ 0xe19622c0 | 0 | 0 |- referent java.lang.reflect.WeakCache$CacheKey @ 0xe165c648 | 32 | 32 |- <classloader> class org.hibernate.boot.archive.internal.StandardArchiveDescriptorFactory @ 0xe17e1428 | 8 | 24 |- <classloader> class org.hibernate.cache.cfg.internal.EntityDataCachingConfigImpl @ 0xe17a78f8 | 0 | 0 |- moduleClassLoader org.jboss.modules.Module @ 0xe05ce818 | 56 | 32,704 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The ByteBuddy TypeCache can be cleared by the Java garbage collector or by manually calling ByteBuddy TypeCache#expungeStaleEntries().

The question is when should we call TypeCache#expungeStaleEntries()? If we could call that at SessionFactory close time, that would help. Perhaps we should call it earlier (e.g. at the end of deployment time perhaps if the cache contents are only used at deploy time)?

See https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/TypeCache.java + https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/TypeCache.java#L167.

Also see https://github.com/hibernate/hibernate-orm/commit/e7bd213c9e32dbb5456f43a6350e54055df73221 and .

Environment

None

Status

Assignee

Sanne Grinovero

Reporter

Scott Marlow

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

5.3.0.CR1

Priority

Major