harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Garner" <robin.gar...@anu.edu.au>
Subject Re: Questions about GC implementations
Date Fri, 21 Oct 2005 22:04:53 GMT
>
> Robin,
>
> Over the last few days as we have all been discussing
> heap and GC, I have been growing mroe curious by the
> hour about what you see as a design critique of the GC
> hooks I defined.  Perhaps I am taking it a bit too simplistically,
> but all I did was define a GC hook anywhere an object or
> array reference or a class load or unload happened.  How
> does your concept differ?  And what sort of approach should
> be used instead.  GC is a completely new area to me and I
> am very interested in learning about what could be done.
> One of these days I'm going to read the standard (Jones?)
> book on JVM garbage collecition, but not today.
>
> Even if you don't have your proposal ready now, I'm still
> interested in hearing how you approach the foundation of
> GC design and how you would approach it on this JVM.
>
>
> Dan Lydick

In the garbage collectors I've worked with, the essential design is:

- 'new' allocates space on the heap.
- The header of each object contains a pointer (or equiv) to a per-class
data structure, that points to the GC map for the object (and virtual
dispatch tables etc etc)
- Reference fields in objects contain pointers directly to the heap
objects they reference.
- Pointer loads and stores are (optionally) performed via barriers - the
terminology is a little confusing: these are not synchronization barriers,
but opportunities for the GC to intercept the load/store and do some
additional processing.  Write barriers are common, read barriers less so.
- There are many styles of collector, but the most common class uses
tracing, in which a root set of pointers is used to determine an initial
set of live objects, and the collector performs a transitive closure over
this set to establish the set of all live objects.  The root set is
commonly the thread stacks and the static pointer fields.
- The above is also complicated by
  . Reference types
  . Finalization
  . Locks
  . Address-based hashing
  The solutions to these are all pretty well known, but complicate the design

This is pretty much it - the rest (45 years of research) is optimizing the
way this is all done.

>           Perhaps I am taking it a bit too simplistically,
> but all I did was define a GC hook anywhere an object or
> array reference or a class load or unload happened.  How
> does your concept differ?  And what sort of approach should
> be used instead.

This I think brings us back to my initial question, asking what these
hooks were supposed to do.  I guess you're saying you had a vague idea
that the GC might need to know about these events, so put hooks in for
them.

When I was looking around the code trying to find out where to start
hooking in a managed heap, I looked for the 'new' or 'alloc' operation,
and couldn't seem to find it.

Interface design for memory managers is an interesting research question. 
Weldon has posted the ORP interface, which I think is probably pretty
close to a good design.  I would make some additional operations explicit
in the interface, and abstract over some of the features that are a
'shared understanding' between GC and VM in the ORP design, but I think a
final design would have a lot in common with it.  The MMTk interface is
the one I know best, and while it isn't perfect in itself, my improvements
to the ORP design would probably involve taking features from the MMTk
interface and adapting them to the environment.

> be used instead.  GC is a completely new area to me and I
> am very interested in learning about what could be done.
> One of these days I'm going to read the standard (Jones?)
> book on JVM garbage collecition, but not today.

Yep - Jones and Lins is the standard reference.  If you're looking for a
good brief introduction, you could do much worse than the wikipedia entry,
which seems to cover most of the important parts.

> Even if you don't have your proposal ready now, I'm still
> interested in hearing how you approach the foundation of
> GC design and how you would approach it on this JVM.

I think its important that the initial interface contains all the features
that have ramifications for the core design ideas of the rest of the
system.  Hope to have a draft out next week.

cheers,
Robin


Mime
View raw message