[java] FuryPooledObjectFactory#classLoaderFuryPooledCache remove softValues

[Shuchang Li]

Is your feature request related to a problem? Please describe.

classLoaderFuryPooledCache with weakKeys,softValues,expireAfterAccess , values removed too frequently. In some case it will create too much fury.

Describe the solution you'd like

I'd like to remove softValues options. even weakKey can be removed too, just remain expireAfterAccess

Additional context

[Shawn Yang]

If we remove it, those classes will never be collected. In some hot-loading classes scenarios, it will may cause class leak

[Shawn Yang]

Maybe we can resolve this in another way. Like let users call Fury to clear classes explicitly.

In this way, we can remove those weak/soft values

[Shuchang Li]

If we remove it, those classes will never be collected. In some hot-loading classes scenarios, it will may cause class leak

I see it could be just remain weakKeys, softValues will cause that fury must create again when after gc.

[Shawn Yang]

If we remove it, those classes will never be collected. In some hot-loading classes scenarios, it will may cause class leak

I see it could be just remain weakKeys, softValues will cause that fury must create again when after gc.

The values can have strong references to keys. If value are not soft references, the weak key won't make the classes eligible for gc. If we remove soft values. The weak keys should be removed too

[Shuchang Li]

If we remove it, those classes will never be collected. In some hot-loading classes scenarios, it will may cause class leak

I see it could be just remain weakKeys, softValues will cause that fury must create again when after gc.

The values can have strong references to keys. If value are not soft references, the weak key won't make the classes eligible for gc. If we remove soft values. The weak keys should be removed too

I'd like think whether softValue or not will not effect weakKeys. weakKeys will take key reference as WeakEntry, and won't effected be valueReference. maybe we can take a test for it.

[Shawn Yang]

The value may have strong reference to key, so the key are always strong reachable, and it' will never be taken as weak. The thing here is that Fury will hold strong reference to classes of user objects.

[Shuchang Li]

I see

[Shawn Yang]

How about removing weakkeys & soft values, we can make org.apache.fury.util.LoaderBinding#clearClassLoader as a method in ThreadSafeFury, and let users to clear classloader explicitly. Then we can remove all weak/soft values in Fury.

The weak/soft values in CodeGenerator should still be preserved, since it's a static global state

[Shuchang Li]

It is a simple way and users mostly time need't to take this method.
if for may way, I'd like clear Fury#ClassLoader, set ClassLoader when gerFury() and clear classLoader when returnFury(). :)

[Shawn Yang]

It is a simple way and users mostly time need't to take this method. if for may way, I'd like clear Fury#ClassLoader, set ClassLoader when gerFury() and clear classLoader when returnFury(). :)

The thing is that Fury itself doesn't support change classloader currently, so we use a map to switch classloaders. Different classloader may have class with same name but different fields. So Fury made the classloader inmutable for simplicity.

But in the long run, it would be great if we can allow update classloader on Fury itself without introducing extra performance overhead.