Xiao-Feng Li wrote:
Archie, thanks for the info, the approach looks like the second one I suggested. We can take it at first.
Hmmm.. guess I don't understand what you meant by "The former approach can reclaim as more as possible VM objects".. could you explain?
Btw, there are some situations I am not sure if the approach you mentioned is possible. For example, we may want to reclaim also VM structures for strings that is not associated with a class loader, or to reclaim some jitted code buffers before the class loader is unloaded, or sometimes we want to put certain data/codes closely together for better cache/branch effects. Suggestions?
Of course, anything not associated with a class loader has to be allocated from somewhere else... The per-loader memory could be a stack, or a (malloc style) heap. The latter allows more freedom regarding when you free things but at the cost of higher allocation times. In many cases, per-loader structures are alloc'd once and never free'd until unloading, so stacks can work pretty good. Stacks also allow freeing on error conditions (you can always free the last thing allocated). Whether you have per-loader data structures that may need to be freed before class unloading depends on how the VM works; in JCVM there are none so life is simpler and a stack structure works fine. If a VM did have this, it could use a malloc style heap instead of a stack, etc. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com
