I think a real solution addresses all native resources, not just memory on the 'C' heap. DaCapo xalan for example (pre dacapo-2006-10-MR1) would run out of file handles in a 512m heap. File handles, certain finite GUI resources etc are all prone to this kind of problem.
The usual design pattern seems to be that when Java code allocates a native resource, it frees it in a finalizer (and better code attempts to explicitly free it earlier), so the issue is not just GC, but also (timely) execution of finalizers. As various people have pointed out tracking the native resource consumption is non-trivial, and it's not something I'm going to attempt to address :) Adding a facility where the GC asks the runtime whether it needs a GC (for one of the above reasons) would IMO solve the problem from the point of view of the GC. Then the VM can track usage of finite resources on its side of the fence, and trigger GC when they are nearing exhaustion. Care is probably required to avoid thrashing: since it is execution of finalizers/reference type processing that frees native resources, there will be a delay between requesting a GC and native resources being freed. For this my first thought is to insert a marker in the finalizer queue, and to ignore GC requests for native resources until all finalizers queued since the last request have completed. I'm glad DRLVM is addressing this issue - it's one that has interested me for a while. cheers (PS apologies for the initial blank reply :/ ) -- Robin Garner Dept. of Computer Science Australian National University http://cs.anu.edu.au/people/Robin.Garner/
