[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
variable size classes
- To: <heh>
- Subject: variable size classes
- From: Eric Dean Tribble <tribble>
- Date: Thu, 9 Nov 89 16:37:51 PST
- Cc: <markm>, <xtech>
- In-reply-to: <Hugh>,37 PST <8911091952.AA05500@xanadu>
Precis: Allocation ideas for variable sized objects and primitive arrays.
I think only primitive arrays are variable sized. Here is the
proposal I recall:
(Primitive) arrays re allocated in a special heap. They are accessed
through handles that participate in the normal garbage collection
operations. When a handle is deallocated, it deallocates the
variable space that it manages. These handle objects give the double
indirection required to implement compaction of variable sized blocks
of memory. Handles on arrays used for copy-on-write tables also have
a refCount field. The refCount determines whether the array is
shared. Table and Set classes that use copy-on-write copy the array
before writing if the refCount is greater than 1.
Independent of all this, Tables and Sets may have to use refCounts to
immediatelyt deallocate when dereferenced. Otherwise copy-obn-write
doesn't help as much (in theory). This is another discussion.
Finally, the above description is to clarify the semantics. With a
good design, we should be able to have array handles with or without
refCounts, allocatre small arrays normally (using the single size
heaps), and lump the refCount into the array and the handle into the
table, if we so desire. I think the simplest solution will be to have
explicit handle objects that act like all other objects: they hide
the variable sized arrray away from normal objects. A separate
compaction routine then manages large spaces. If the implementor has
a better idea, great! (I'd like to hear it though).