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

[John Carter]

Sorry for the delay in reply, I was away for 10 days...

On Mon, 20 Jan 1997, Richard A. O'Keefe wrote:

> 	>  _I_ find it hard to believe that brute force copying would usually
> 	> be cheaper than 2 instructions.
> 	Ok, maybe you have convinced me. Actually 3 instructions, you forgot
> 	to inc the refcount.
> I forgot nothing.  In the unique reference case, the reference count
> does not change.

Nope. 3. On creation the refcount must be initialised, on lazy copy, the
refcount must either be incremented or an even more expensive test
made to check whether it is already in the "shared" state. (What
happens if the refcount overflows?) Thus every copy implies at least a
"mov" or an "inc", and a "ld" and "beq" on mutation. Still, I admit
defeat, you're right, it is cheaper. The unique reference doesn't help
you, because you don't know how many lazy copies have been done, so if
you don't count them you can end up doing one too many copies.

> 	> Come off it!
> 	> There is *never* any need to copy *immutable* 'objects' of any kind.
> 	> Integers and floating point numbers are intrinsically immutable.
> 	> Copying (and copy optimisation) only apply to *mutable* objects,
> 	> where there is some operation that can change some *part* of an object.
> 
> 	Huh? I'm confuzzled. Speaking C++ because it so easy to illustrate
> 	messes in...
> 
> Exactly so.  C has confuzzled you.  In Smalltalk, SETL, Lisp, Prolog, Dylan,
> NewtonScript, you name it, numbers are VALUES.
[skip]
> The thing that has confuzxzled you (lovely word) is that I was talking
> about INTEGERS and you were talking about INTEGER VARIABLES.  Yes, you
> can change an integer variable, but you can't change an integer.
[skip]
> In none of this did any *integers* changed.
> The *contents* of some *boxes* changed, but that is another matter entirely.
> After the command
> 	i := cont(j)
> i and j are distinct _boxes_ containing the same _value_.
> We might say that i and j both contain the object identifier for the
> object 3, and the object 3 has no user-accessible parts that could
> possibly change.  Any number of boxes can safely contain the object
> identifier of the object 3 without any need ever to copy 3, because
> 3 cannot change.
[skip]
> computes 40! = 815915283247897734345611269596115894272000000000
> which at 48 digits is too big for the registers of most machines.  So it
> is in practice represented as a pointer to some sort of data structure,
> BUT that data structure is immutable, so pointers to it can be passed
> out to anyone that wants one, without ever bothering to make a copy
> of that particular number object.

Aha! The difference is I come from an Applied Maths background where I
toss around millions of these numbers, creating a new one every
microsec. I can't afford to have them all garbage collected. I can't
afford a Platonic view of the numbers, all in abstract glory pure and
undefiled. To me there is a continuum from the integers modulo 2^31 to
arbitarily complex data structures, the only difference being that the
big data structures don't fit into the word size my computer. A "mov"
instruction to me is semantically the same as "memcpy", just a lot
faster and more limited. I agree that you can't change the Platonic
number 3. But I sure do a lot of fiddling with the number of kilograms
of salt in the estuary I'm modelling.

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.