Erik Corry wrote:
> There's a lot to be said for this, but since you can allocate > unlimited memory in an exception handler, every point that can > throw an exception has to be a safe point [...] If exception is thrown, you don't care about registers (unless you write-cache locals in registers, but it will give problems even without precise gc), you don't care about stack. SO you only have to care about local var map, stack/register map is important only for safe points INSIDE exception handler. Local var map can be optimized, as it is common for a lot of places in code (so for method you would just create few maps with ranges of addresses for which they are valid). I'm afraid that you will not be able to avoid making stack maps and using safe points. You need to know about registers - I don't think that splitting register into reference and non-reference is reasonable on i86. You also need to mark which local variables are live and which are dead - because if you will use dead object pointers as live, you are non-precise and possibly unstable (as it can point inside some newly allocated object). But if you have variable map with local liveness you can as well add object/primitive distinction there and forget about explicit separation in memory :) Safe points should be made on new/newarray/multinewarray monitorenter/monitorexit method call backward branch First three are obvious, backward branch is for tight loops which got preempted and are possibly endless, but gc needs to run (you cannot create endless loop with forward branches, so it is not a problem). AFAIK, hotspot stops thread, replaces closest safe points with some trap and let thread run until it hit one. Then it restores original instruction and voila. Generally - it is hard. Not even stack maps and their representation, but getting everything working with threads in efficient manner. Artur
