[M3devel] small objects

[Mika Nystrom]

My code just shifts the word over by one and sets the LSB to 1.

Same as in the Blue Book (that's "Smalltalk-80" by Goldberg and
Robson).

    Mika


Jay writes:
>
>Can we say that anything under 64K is invalid?
>And in RTAllocator, do some gymnastics to make it so?
>In particular, like:
> if an allocation from memmap/malloc/sbrk is under 64K:
>   if it is "small", leak it, and try again 
>   if it is "large", free it, and try again 
>   This does not guarantee forward progress in the large case.
>   So, if it is large...?
>   Free it, allocate something small, if it is under 64K, leak it, and try again.
>   If it is not under 64K, free it, allocate something larger?'
>   This is better, but can still loop forever.
> 
>I guess sbrk returns always increasing addresses?
>If you chose 4K instead of 64K, easier/more portable, given that all existing systems have page size>=4K and NULL is invalid, so 0-4K are invalid.
> 
> - Jay
>
>
>----------------------------------------
>> To: hendrik at topoi.pooq.com
>> Date: Sun, 29 Mar 2009 12:31:19 -0700
>> From: mika at async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] small objects
>>
>> I asked Tony about this and he said that currently it will confuse
>> the GC but that it's a minor change.
>>
>> I wanted it for my proposed Smalltalk-in-M3 environment, which has
>> since morphed to a Scheme-in-M3 environment (much easier to code),
>> and I would still like it :-) (But I have plenty of other issues
>> in my environment also that need my attention more urgently
>> at the moment...)
>>
>> Mika
>>
>> hendrik at topoi.pooq.com writes:
>>>There are many times I want to express data which could be efficiently
>>>coded as the disjoing union of (small) integer and pointer to object.
>>>The pointer-to-object is used in the case where tho objects are big;
>>>the (small) integer for the more common case where the objects are
>>>small.
>>>
>>>High-level languages seem to pe quite paranoid about admitting thise
>>>kind of data into the fold, except maybe for Lisp systems, which have
>>>been doing this from time immemorial. (I believe CAML does this, too).
>>>These languages use it internally, and manage to (mostly) hide it from
>>>the user.
>>>
>>>The X toolkit uses this trick too -- there's a constant somewhere, and
>>>if an integer is less than this constant, it's passed to an X toolkit
>>>function as an integer; otherwise by reference. The idea there is that
>>>there's a range of addresses of storage that can never be used as
>>>parameters for the X toolkit functions (presumably because of hardware
>>>or OS limitations), and that the bit patterns that are unavailable for
>>>addresses can be used as small integers.
>>>
>>>Now the semantics of such a union, efficiently coded, are quite clear.
>>>There's a range of numbers that can be packed unamiguously into
>>>pointers, and if your integer can be so packed, you do it;
>>>otherwise you use a reference to sime kind of INTEGER object
>>>elsewhere. There are operations for packing integers and object
>>>pointers into such words, and others for unpacking them (complete with
>>>type-test). The actual physical representation can be machine- or
>>>implemetation dependent -- you could do a bit of shifting and pack
>>>integers into words with the low bit set (if pointers to objects are
>> usually aligned in some way, the integers will stand out as being
>>>unalinged) Or you could use an uppoer bound on "small" integers, as C
>>>does. And on a machine where such packing is impossible (for whatever
>>>reason) you could simply set the upper bound of (the absolute alue
>>>of) such packable integers to be zero, so there wouldn't be any.
>>>
>>>Is there any way such a thing can be done in Modula 3? Remember -- I do
>>>want the garbage collector to be aware of such conventions and do proper
>>>tracing on the pointers?
>>>
>>>(I suspect the answer is "no". But would be a pity.)
>>>
>>>-- hendrik