The future of "frozen" types as the number of CPU cores increases

[John Nagle]

Daniel Stutzbach wrote:
> On Tue, Feb 16, 2010 at 3:15 PM, John Nagle <nagle at animats.com> wrote:
> 
>> One possible implementation would be
>> to have unfrozen objects managed by reference counting and locking as
>> in CPython.  Frozen objects would live in a different memory space and be
>> garbage collected by a concurrent garbage collector.
>>
> 
> A concurrent garbage collector for frozen object would still need to walk
> unfrozen objects, to find references to frozen objects.

    Right.  But the reverse is not the case.  Reference count updating
wouldn't need to look at frozen object space.

    One way to implement locking is something like this:

    Mutable objects have a reference count field, a lock field,
and an "owner" field.  Initially, the owner of an object is its thread.
If an object's only reference is a field of a synchronized object, the
owner is the synchronized object.  Mutable objects with an owner can
be manipulated by that owner without locking.

    When an object reference is passed to another thread or
another synchronized object, the object becomes multi-owner and
the "owner" field is set to null.  Thereafter, the object must
be locked during updates.

    The headache with this is that when an object becomes multi-owner,
so does everything it points to.  So there's a transient as the
system runs down the references, locking objects momentarily and
clearing owner fields.

					John Nagle