Re: [rvm-research] a possibility of merging mark and compact stages

[Da F. <jvf...@ya...>]

Hi:

What if object reference implementations contains two addresses, one is the 
present object address, and another is the pointer to moved object address. The 
second address is used only during GC. Each object holds a pointer (in available 
words) to the second address? After objects are moved, it updates the second 
address content. Then GC closure will update the first address. Certainly, 
manage the second pointer address need special care. That means one reference 
takes two address size.
By the way, I uploaded MW to research achieve. It can pass test but performance 
is 70% or 80% of Immix, so it is not worth while.

 
DaFENG
Coder
Telecommunication && Network Industry
Pudong
Shanghai
China




----- Original Message ----
From: Eliot Moss <mo...@cs...>
To: "General discussion of Jikes RVM design, implementation, issues, and plans" 
<jik...@li...>
Cc: Da Feng <jvf...@ya...>
Sent: Sat, August 21, 2010 10:11:17 PM
Subject: Re: [rvm-research] a possibility of merging mark and compact stages

On 8/21/2010 10:04 AM, Da Feng wrote:
> Hi everyone:
> If reference in JikesRVM is implemented indirectly, mark compact GC's two 
>stages
> can be merged. A reference is a pointer and points to the object address.
> The reference pointer is constant, and the content aka the pointed to address 
>is
> mutable. Then after the marking phase, markcompact just moves objects to 
>compact
> the space and update the reference pointer content. Each object should hold a
> field recording the its own reference, so that when its position changes, the
> reference target address can be adjusted.

Yes, it's well-known that object tables allow this.
See, for example, early implementations of the
language Smalltalk.  People moved away from it
because the level of indirection slows down
everything *else* so much, and increase cache
footprint and TLB pressure.  I've not seen a
really recent comparison, but suspect those
older results would hold up.

I do recall seeing an object table approach
used for embedded devices. The advantage was
no so much speed as simplicity of design, IIRC.
Also, the particular paper I am recalling, from
an OOPSLA a while back, also performed *compression*
on objects not recently used, and the level of
indirection allowed transparent decompression.
The compression more than made up for the space
overhead of using an object table ...

Hope these thoughts help you in your own
thinking ...

Eliot Moss