[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Limbo, here I come !!



> 
> >This is confusing to me.  I thought the point of garbage collection
> >was that you don't have to think about the state of the memory after
> >allocation.  What is the point in exposing details of the implementations
> >of the garbage collectors unless the application is going to think about
> >the allocation state of some memory.  And if this is the case, why not
> >just use an explicit malloc/free management scheme.  Is there some
> >gray area in between totally explicit management and totally automatic
> >that eludes me?  Can you give a compelling example why I would want this
> >in-between type of management?
> 
> 	postmenu(m)
> 	{
> 		window := draw_menu(m);
> 		case getmenuinput(window)) {
> 		"first" =>
> 			postmenu(m.first);
> 		"second" =>
> 			postmenu(m.second);
> 		}
> 	}
> 

Correct me if I'm wrong, in this example, the invokation of postmenu
allocates some memory for m that under lazy gargage collection would 
be deallocated at some non-deterministic future time after exiting this
routine?  And (based on below), segments of m are selectively deallocated
when recursive calls are made?

> In this fragment recursion holds successive window
> references for sub-menu's. The sub-menus will be
> unposted by the runtime when the local variable
> window goes out of scope. The structure of the program
> reflects the structure of the user infterface which
> is nice and idiomatic for the the programmer. If
> the garbage collection were lazy he would have
> to schedule the clean up. Clearly in this case that
> would be trivial but the example illustrates the
> point. The semantics of the garbage collector are
> useful.
> 

Agreed, however, the question I had was about exposing explicit details
of the garbage collectors data structures, I believe you referred to
a reference count and/or some coloring.  Neither of those elements are
referred to in this example.  In fact, this example makes no reference to
explicit allocation (other than implied semantics) or deallocation which is
nice.  Can you provide an example where you would use these heap attributes
in a way that is compelling over just using explicit management.

Actually, after thinking about it some more after my first post, I did
come up with an answer, at least for myself.  Current systems provide
explcit management by default.  Implicit management must be layered over
this semantic if needed.  Perhaps the answer is that for performance (of
the implicit management) and ease of use, its better to make implicit
management the default and provide the programmer a hook to do explcit
things if they need to.

I'm still interested in an example where this might be considered the
`best' solution to the problem.

Later,
FM

--
Frank W. Miller                           Department of Computer Science
fwmiller@cs.umd.edu                 University of Maryland, College Park
http://www.cs.umd.edu/~fwmiller             College Park, Maryland 20742