From: Steve B. <Ste...@an...> - 2002-08-15 04:53:01
|
Hi Mike, > I'm working on my Java JNI implementation and I would > like to modify the GC algorithms in the RVM to handle > explicit malloc and freeing of Objects to allow > integrate with native code. What this means is the > user can explictly free a object this is similar to a > weak reference getting collected but forced. A student I'm working with has implemented explicit memory management in GCTk (he wanted to compare explicit MM with GC). > Do any of the collectors support weak references ? Not yet, but take a look at the jikesrvm-researchers mailing list. There was a question about this yesterday. A student at UMass is working on it and it should ultimately be supported in JikesRVM. > Which gc should I use as a base > I think markAndSweep is the simplest "real" gc ? I don't know what you mean by "real", but you probably do want to use a non-copying GC (such as markandsweep). > Allocation is no problem but implementing free is > intresting. I think I need to do the following. > > Determing the block I wish to free. > > Run a modified GC algorithm which nulls all > referencesto block/object > > Allow regular GC to collect the object. > > Or I can simply add the blocks back to the free list > leaving dangling pointers similar to the C free. > I'm not clear on what steps must be taken to mark and > object as freed is setting live to false enough ? This is entirely up to you. This is the problem with explict memory managment: what semantics do you get when you delete an object to which there are still references? This is not an implmentation question but a design decision. > Also I need to pin the malloced objects since the > malloc by default says the object is accessed from > native code. You could easily do this (as JNI implementations usually do) by maintaining a list of all references maintained by native code. This list is concidered as a root set from the GC's point of view. > Finally is there a generic approach to allow this for > all collectors that I'm missing ? Perry Cheng and I are doing a major re-work of the collectors. Influenced by my student's experience, I intend to include much more natural support for explicit memory management. So much so that we're tentitively calling the new toolkit JMTk, the M standing for "Memory management" rather than "GC". In other words, we're explicitly considering explicit memory management as part of our design (not just GC). Having said that, I'm not 100% sure what you want. If you just want to be able to say in native code: alloc an object, free an object, then all you really need to do is maintain a list of JNI-alloced objects and once JNI calls free, remove the corresponding reference from the list, at which point the object will be collected as soon as there are no non-JNI references to the object. THe list simply gets treated as a root set by the GC. This is generic and easy to implement. Of course unless you introduce an extra level of indirection, you'll be restricted to non-copying GC. Cheers, --Steve |