More PC Precision Stuff

[dsimcha]

== Quote from Lutger (lutger.blijdestijn at gmail.com)'s article
> dsimcha wrote:
> > I've gotten underway hacking the GC to add precise heap scanning, but I
> > thought of one really annoying corner case that really would make things
> > an
> > order of magnitude more complicated if it were handled properly:  Structs
> > and
> > classes that have large static arrays embedded.  For example:
> >
> > class Foo {
> >     Foo next;
> >     void*[4 * 1024 * 1024] hugeArray;
> > }
> >
> > The problem here is that scanning this precisely would require me to
> > either generate a megabyte bitmask that explicitly says "scan every
> > element of hugeArray" or to change my bitmask data structure from a flat
> > array to something nested and an order of magnitude more complex to
> > generate at compile time.
> >
> > Since this is such a rare case in practice, I'm tempted to just say that
> > any object with size above some arbitrary limit, say 1 kb, just gets
> > scanned
> > conservatively and be done with it.  For arrays, this would be a limit on
> > the size of the element, i.e. for a T[], it would be a limit on T.sizeof,
> > *not*
> > T.sizeof * length.  I'd like to get the community's input on this:  Is
> > this enough of a corner case that I have permission to cop out of solving
> > it properly for the sake of simplicity?
> Could you or anyone else solve this problem at a later stage? If that would
> not be made more difficult then I would say cop out, at least for now.

I would be much more inclined to cop out on this, except that I would be making a
design decision that might not be easy to change in the future w.r.t. how bitmasks
are structured.  If we eventually fixed this, it would likely be a breaking change
to the GC interface, after D2 had gone gold.  Then again, GC.malloc is a pretty
low-level interface, and most access would be through whatever replaces new, which
would likely be in the standard lib and could be modified in lockstep.  Therefore,
if/when we were to get a more principled scheme, it might be transparent to most
user code, at least at the source level.

One thing I definitely need to know from the insiders (Walter, Sean, etc.) is, how
much do we care about having a stable, well thought out, formally specified
interface to the GC routines, both at the source and binary level, at this stage
in the game?  If I did something hackish to get precise heap scanning mostly
working, would the patch likely be rejected because it would create cruft that
would have to be kept for backwards compatibility?