Hi Gilbert --
Unless I'm misunderstanding you, what you're suggesting sounds very like
referencing counting. (With each new reference to an object, the ref count
is increased by one; each removed reference decreases the count by one; when
the count is zero the object is free.) It has two problems that I'm aware
of:
1. it can't cope with cycles of objects. If a refs b and b refs a, then
their ref counts will always be at least 1, and the objects will never be
freed.
2. performance isn't great (apparently -- I've no personal experience of
implementing this).
The gc currently implemented in decaf will do the tidy up of object graphs
when a class loader is destroyed -- if the cl is no longer referenced, then
it, and any objects hanging off it, will be freed at the next gc (assuming
that nothing else references the objects of course).
Regarding object refs being handles, my understanding is that yes, that's
effectively true in decaf at the moment. There's a java_object handle for
each object, and this contains a pointer to a lump of memory holding the
object's Java fields. It doesn't need to be this way though - see the tech
docs on HotSpot, which doesn't use handles. An advantage of handles is that
it simplifies implementing a moving garbage collector (such as we *don't*
have currently); a disadvantage is that the indirection probably decreases
performance slightly.
-- George
> -----Original Message-----
> From: Gilbert Carl Herschberger II [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, December 09, 1999 13:06
> To: [EMAIL PROTECTED]
> Subject: Re: [JOS-Kernel] Next version of jjos / decaf garbage
> collection
>
> 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
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
