[gclist] When to collect.

[Bill Burcham]

	-----Original Message-----
	From:	Jerry Leichter [SMTP:leichter@smarts.com]
	Sent:	Thursday, November 20, 1997 9:21 AM
	To:	gclist@iecc.com
	Subject:	Re: [gclist] When to collect.

	<<good stuff omitted>>

	This would be the third class of interfaces that OS's could
provide to help GC
	that I know of.  (The first two are "stop all threads in this
process other
	than this one", which makes concurrent GC's much simpler; and
cheap,
	reasonable ways for user-level code to handle VM exceptions,
allowing things
	like using read-only pages for write barriers.  Perhaps a
general, efficient
	way for user code to deal with VM events could be used to build
an "optimal
	size" mechanism, but I doubt it:  Good feedback depends on
global information
	about the system, and such information isn't, and probably
shouldn't be,
	handed to user page fault management code.)
								-- Jerry

	This reminds me of a paper I read a couple years ago on
"Scheduler Activations".  The problem that it solves is: threads are
really the wrong abstraction - i.e. it presents the wrong interface.
Because of this, systems built using threads are always non-optimal.
Scheduler Activations is a whole new abstraction (logically a
decomposition of the threads one) which can be used to build e.g. the
(broken) threads interface, but also alternate more performant ones.

	The Scheduler Activation interface delegates to the (user)
process decisions about certain events related to scheduling.  This
could e.g. be used to build useful scheduling policies such as
Proportional Share Lottery or Stride schedulers (Carl Waldspurger's
work) as opposed to the (broken) priority-based approaches which
dominate currently.

	I have always thought (for the last few years at least :-) )
that it would be interesting to study the analog to Scheduler
Activations but for memory management.  Recent posts to this list such
as the ones regarding open interfaces for Smalltalk memory management
show that a certain amount of this already occurs.  But it seems that
like the "threads" interface, these current attempts at "openness" fall
short - which brings up my final point.

	Does it seem to anyone else that "scheduling" and "memory
management/GC"  and "persistence/transactions" are deeply
intertwingled?!?  If you go read the Scheduler Activation work you will
notice that many of the events of interest to that interface are
identical to those which would be interesting to memory management.
Also the same events are of interest to persistence systems like
ObjectStore or Texas Persistent Store, e.g. hardware memory management
events like: a reference to a virtual address which is not currently
mapped into physical memory.  ObjectStore/Texas needs that event to
"fault-in" objects and lock pages, a garbage collector might need that
event if it employed a hardware read or write barrier.  You want these
things to work _together_.

	I realize this was a bit of a ramble, but I believe the ideas
are related.  It seems like they all stem from the ancient and primitive
(read as lowest common denominator) interfaces provided by our operating
systems.  Seems like now that we have all this sophistication and
experience developing, e.g. OO frameworks for applications, that we
could really do something interesting at the System level to solve the
problems better. 

Bill Burcham			         ObjectSpace, Inc. 
mailto:bburcham@objectspace.com    http:\\www.objectspace.com