[gclist] Memory cheats and VM (was Counting on one thumb)

[John Carter]

On Wed, 15 Jan 1997, Richard A. O'Keefe wrote:
> The previous writer didn't say "valid in *MOST* current languages", but
> "valid in current languages", which I took to mean "SOME current languages".
Point taken.


> no *programmer-visible* sharing.  (At least one SETL implementation did
> this by keeping a reference count on each object.  Just before you
> modify part of an object, you check the reference count.  If it is
> greater than 1, you make a copy (with reference count 1) and decrement
> the reference count of the original. 

I find it hard to believe that this would be more efficient that brute
force copying! Or is this a relict of memory short days like ye olde
Vax BLISS? Or is my intuition here out? Or did this just apply to
"big" objects and little ones like int&double were copied immediately?

> I believe that the current
> language SETL2 still gets the same effect; by what means I have no idea.
I was tossing ideas about of looking at the dataflow graph and only
actually letting the compiler put in the copy if possibly needed. But
I regarded this as a "finishing touch" rather than a core
implementation issue. One could also use COW. In fact that was an idea
I have been contemplating but I don't know if it is practical.

How expensive is it to play with VM? Could one implement every
aggregate object as a separate VM segment on a i*86? Anyone with any
experience on that? (Yip, I know its stretching the design paradigm,
but it would be very useful. All that bounds checking, indirection,
etc etc all done in hardware and all being done every time in any
case. Just think, no need to fiddle your users pointers after GC, just muck
with the segment descriptors!)


John Carter                    EMail: ece@dwaf-hri.pwv.gov.za
Telephone : 27-12-808-0374x194 Fax:- 27-12-808-0338

Founder of the Council for Unnatural Scientists.