[M3devel] small objects

[Tony Hosking]

No good if the tag bits are the same as unaligned pointers from the  
stack/registers -- we'd end up conservatively pinning pages that just  
happened to have addresses that coincide with the tagged values.

On 30 Mar 2009, at 07:25, Jay wrote:

>
> You can also depend on heap being somewhat aligned and use the lower  
> bits as "tag" bits. Like, if you need all 30bit integers to be not  
> heap allocated or somesuch.
>
> - Jay
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: mika at async.caltech.edu; hendrik at topoi.pooq.com
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] small objects
>> Date: Sun, 29 Mar 2009 20:19:32 +0000
>>
>>
>> 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