[M3devel] small objects

[Jay]

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