Alex Tkachman schrieb:

I am aware of that, but the logic is not the right direction. The class becomes unloadable once the thread is stopped, the thread stops once the ref count is 0. We basically have here a pair of reference and referent. The ReferenceQueue will have a hardlink to the reference, while the referent might be collected. So when the GC is running now and freeing all referents, then your Thread is most probably still running, meaning the class and the loader cannot be unloaded. The Thread is still running, because the Thread is not executed as part of the GC process, but in parallel. The GC would at last need a second sweep after the thread is done. And I think that is too much for the GC.

I spend Monday+Tuesday on refactoring many of the classes for a more flexible memory management. What I did was:

Abstract the reference types java gives.I have now an enum for defining the reference type and FinalizableRef became ManagedReference. LayzySoftReference became LazyReference and can now be used with soft, weak, phatom or hard references. Your soft and weak maps got replaced by ManagedConcurrentMap and ManagedDoubleKeyMap. Since they now have a configurable reference type, there is no longer any need to have a special map for soft and weak. I have now a ReferenceManager class, with 4 possible versions, one manager that collects references from the ReferenceQueue by thread as done before. One that is callback based like I 1.5.x, one that does nothing and one that changes to a different manager once a threshold is reached.

Yesterday I spend most of the time finding a memory leak, which I found in my implementation for the strong meta class tracker. That implementation was confusedby GroovyShell#evaluate trying to unset the meta class of the script class in the registry. The tracker recorded that accidently as an action where a string meta class has been unset and build up references for it. It is a very small memory hole, because with even only 7mb ram I could run the test around 20k times before it blew up.

So what is left? Currently the memory manager are set statically in three places, that probably should be only one place. The ideea of not starting to collect references right away seems to work well, but I need to check how many references I need to start a small application. I would like to have it so you can start a small application without any memory management and once a certain count is reached, we start to manage. So fine tuning is required.

What is also missing is the public API to control anything here. I needs to be something static it seems, so maybe something hosted in GroovySystem would be fine. But since there are currently three places and four cases, how much control do we want to give? I think we could make all 4 cases into one, meaning there will be only one manager and one reference queue.

I did not run any speed tests, the only thing I can currently say is, that the build needs about the same time on my machine.. ah well, the weak map test is currently failing, because I removed the assignableMap, because it was not used

anyway... how should I proceed? Simply commit what I have once I fixed the test?

bye blackdrag