[gclist] When to collect.

[P. T. Withington]

At 09:20 -0500 11/20/97, Jerry Leichter wrote:
>However, you get the vicious circle:  Since it's hard to
>get good feedback from OS's, GC's don't try very hard, so OS's see no demand
>for better feedback (not that GC'ed languages loom large in most on the list
>of things most OS designers worry about....)

I have hopes that Java may change that.

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 read protect pages (ideally, still permitting writes)
o write protect pages and/or be able to examine "dirty" bits
o pre-process pages that are candidates for page-out
o mark pages as "clean" (to avoid page-out of stale data)
o handle protection faults, possibly by simulating the read
  or write in software
o be able to "peek" at protected pages (e.g., have a priviledged thread)
o find out what pages are resident and non-resident
o pre-fetch and post-purge non-resident pages
o remap pages from one virtual address to another

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

There are also page table structures that will improve the performance of
garbage collected systems, if the underlying hardware permits a choice of
page table structure.

---
P. Tucker Withington, Harlequin Inc., One Cambridge Center, Cambridge MA 02142
Phone: +1 617 374 2557       Fax: +1 617 252 6505      "Honk if you love GC's"
The Memory Management Reference:  <URL:http://www.harlequin.com/mm/reference/>