[gclist] When to collect.

[Jeremy Fitzhardinge]

P. T. Withington wrote:
> Here's my favorite list of things I'd like to see in O/S's to support GC:
> 
> o reserve virtual address space.
> o handle "unmapped" faults, assign backing store, initialize (possibly
>   to computed value, not always 0)
> o unmap pages, unassign backing store, but retain address space
> o mark pages as "clean" (to avoid page-out of stale data)

These are all possible on current Unixish OSs with various combinations
of mmaping from /dev/zero.

> o find out what pages are resident and non-resident
> o pre-fetch and post-purge non-resident pages
> o pre-process pages that are candidates for page-out
> o handle protection faults, possibly by simulating the read
>   or write in software

All possible in prinicple, but rarely, if ever, implemented.

> o read protect pages (ideally, still permitting writes)
> o write protect pages and/or be able to examine "dirty" bits

You can generally make pages read-only pretty easily, but lots of common
hardware doesn't allow write-only pages: the best you can do is make
them no-access and allow writes in the fault handler, which as you say,
is slow.

> o be able to "peek" at protected pages (e.g., have a priviledged thread)
> o remap pages from one virtual address to another

I've used remapping within a process to simulate a priviledged view of
an address space.  The mutator's view of the heap is often RO, but the
GC thread has another view at a different virtual address which allows
RW access.  Linux allows mapping from /proc to get these effects, but
its often very hard to convince other operating systems to do it.  You
can sometimes fake it using mechanisms like SYSV shared memory, but it
gets very ugly.  Its also hardware dependent: if you've got a Sparc with
virtually-mapped caches, you're going to have to pay careful attention
to strategic cache flushes.

> Note that most O/S's have a relatively expensive mechanism for user-code
> handling faults (on the order of 500 instructions). I would like to see a
> much speedier fault-handling mechanism.

Quite often the kernel code for page faults is not very tuned, since
"only buggy programs page-fault".  I was able to improve Linux's
user-mode fault handling by over 20% just reversing two lines in the
kernel fault handler.  No doubt better performance could be attained
with some serious tuning.

> Similarly for access to O/S data
> structures or state info such as page status (mapped/un, resident/non,
> dirty/clean, protection mode, etc.)

It seems to me relatively low-risk to give a process a read-only mapping
of its own page tables, which would allow it to see hardware features
like dirty-bits.  Of course, you'd need to get more involved in the
overall VM activity, since the hardware's view of a dirty page needn't
correspond with the "logical dirtiness" of a page.

When people talk about Java chips, I can't really see the need to put
the bytecode in hardware, but I wonder what support they're putting in
for efficient GC: that's the hard problem.

	J