Rana Dasgupta wrote:
On 2/8/07, Robin Garner <[EMAIL PROTECTED]> wrote:
>My point was that by adding a single GC -> VM interface function, all
>types of native resources could be addressed in a simple extensible way.
>The subsequent policy and mechanism decisions then become an ongoing
>design process for the VM and classlib native implementers, but once
>this interface function is added, GC can support freeing of native
>resources by whatever mechanisms the VM chooses to implement.
I don't understand very well how the JVM can define policies on its
platform/OS resource usage when it may be hosted by a server which wants to
define such policies itself. In other words, say the JVM is running an
RDBMS
managed stored procedure. Should it be making assumptions about how much
native heap to use etc. when the hosting RDBMS may have negotiated such
policies itself and may be choosing to invoke one or more instances of the
JVM?
This is an interesting issue but I don't think it's relevant to the
design of the interface.
In fact it's a perfect illustration of why the GC should defer policy
decisions to an opaque VM API function, so that the VM is free to
negotiate policy (or lack thereof) with its surrounding environment.
--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/
