Free memory for classes loaded and no longer needed
Project: | JNode Core |
Component: | Code |
Category: | task |
Priority: | normal |
Assigned: | Unassigned |
Status: | active |
Jump to:
Description
Reproduction:
1. Run mauve testsuite in JNode with 512MB RAM
Actual result:
Most memory is used.
The memory needed for loading the classes is never ever freed (until restart of the machine).
Expected result:
All memory, without exception, used when running an application is freed again, to be available for running another application. Running an app should leave no traces after more usage of jnode.
This is, essentially, a leak. The fact that it could be re-used is not relevant, if I don't want to start the app again.
- Login to post comments
#1
While I agree that the current implementation is not perfect, always freeing application classes after use is likely to lead to serious performance degradation. A better strategy would be to keep the machine-code-compiled application classes in memory in an LRU cache, releasing them as and when JNode runs out of memory.
Either way, this is going to be a hard feature to implement. Issues that need to be addressed include applications that share classes, applications that load classes via Class.forName, applications that load plugins, application threads that run after the 'main' thread has exited ... and all of the complications of the use (or not) of isolates. All of these combine to make it hard to know when it is safe to free a class.
#2
> keep the machine-code-compiled application classes in memory
> in an LRU cache, releasing them as and when JNode runs
> out of memory.
That's more or less what I meant. It's a cache, and as such is useful, but must never interfere with other, current usage of memory.
#3
We are probably splitting hairs, but I prefer the current imperfect behavior to no caching at all ... which (I expect) would result in terrible performance when running commands. Also, "must never" is too strong. There are JNode use-cases where permanent caching of all loaded classes is likely to be the right option.
Anyway, this is an important issue that needs to be addressed in longer term. Unfortunately, I don't think we have the expert developer cycles to deal with it right now ...