On Wed, Sep 17, 2008 at 8:24 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

>
> Am 17.09.2008 um 17:10 schrieb Paolo Bonzini:
>
>  Bert Freudenberg wrote:
>>
>>>
>>> Am 17.09.2008 um 07:47 schrieb Paolo Bonzini:
>>>
>>>  Keith Hodges wrote:
>>>>
>>>>> I tried normalizing object
>>>>> pointers to a known base address as a starting point.
>>>>>
>>>> Changing the base address might make loading slower.
>>>>
>>>
>>> Actually, it makes it faster.
>>>
>>
>> Yes, but that address might vary between systems.  I interpreted Keith's
>> sentence as "normalizing the base address to zero", not to something
>> that is likely to be available the next time around.
>>
>
> You can give a desired address to mmap(). We might find one that is likely
> to work on all systems.
>
>  If the VM saves the objects with the current base address, it would
>> probably choose an address that is likely to be available the next time
>> around, but it might be different from what is under version control.
>>
>> Anyway, with direct object access (no OOP table) there is a fundamental
>> problem that makes diff encoding of images almost impossible.  If an
>> object dies, everything after it is compacted and changes its address.
>> If you have an OOP table, the objects are referenced through something
>> that is never compacted, but if objects are accessed directly then every
>> pointer in the image is changing.
>>
>
>
> As long as the garbage collector does not change the order of objects, the
> vast majority of oops in a saved image will not change even in a
> direct-pointer model with a fixed base address. Also, I've been thinking
> about freezing the lower part of the object memory to speed up gc - it makes
> no sense to always trace from the very beginning when most of the objects
> there are never modified (classes etc.). Something like perm space in VW ...


You know that's not how the GC works in incremental (high frequency) mode,
right?  The GC starts from young space using the rootTable as roots.

Further, when the GC does a full GC it does a full trace (necessary) but
only compacts from the lowest free.  You could easily simulate perm space
simply by adding a new generation, e.g. middleAgedStart.  But the store
check would be 1 comparison against a global more expensive (i.e. nearly
twice as expensive, at least in code size).


>
>
> - Bert -
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080917/23c411a3/attachment.htm