I am talking out of turn again; but, why not do garbage collection for
very-large-objects just like technique used for shared libraries?
>From a requestor's viewpoint, the kernel provides a system-wide unique
handle for the instance of a shared library. A shared library has many
simultaneous handles. When a library is open'd, a new handle is created.
When the handle is close'd, only the handle goes away -- unless it is the
last handle.
A virtual machine could use multiple object graphs, each gc'd
independently. Object "references" in a virtual machine are handles (aren't
they?). So, why doesn't a virtual machine provide many simultaneous handles
to an object? When the last handle is closed, the object is gc'd.
When the virtual machine returns a handle, it can be encoded in any form
the virtual machine wants. This is similar to the machine interface of
OS/400. It is also like a "map" of virtual storage, where a "memory
address" is a reference to a page on disk.
It is also similar to the way "links" work on the Linux file subsystem.
Many links can be references to a physical file. A physical file is garbage
collected when the last link is removed.
Wouldn't this be great? A a virtual machine could closely track a class
loader with an object graph, so that an entire object graph is
garbage-collected when the class loader is destroyed. Thinking of the
object graph in terms of "local" and "global" underestimates the scope of a
virtual machine. Just like C/C++ provides for "static" references, private
to a module, a virtual machine might have an object graph for a class
loader (and thus a process).
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
