<div dir="ltr"><br><br><div class="gmail_quote">On Wed, Sep 17, 2008 at 8:24 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Am 17.09.2008 um 17:10 schrieb Paolo Bonzini:<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Bert Freudenberg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Am 17.09.2008 um 07:47 schrieb Paolo Bonzini:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Keith Hodges wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I tried normalizing object<br>
pointers to a known base address as a starting point.<br>
</blockquote>
Changing the base address might make loading slower.<br>
</blockquote>
<br>
Actually, it makes it faster.<br>
</blockquote>
<br>
Yes, but that address might vary between systems. I interpreted Keith's<br>
sentence as "normalizing the base address to zero", not to something<br>
that is likely to be available the next time around.<br>
</blockquote>
<br></div>
You can give a desired address to mmap(). We might find one that is likely to work on all systems.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the VM saves the objects with the current base address, it would<br>
probably choose an address that is likely to be available the next time<br>
around, but it might be different from what is under version control.<br>
<br>
Anyway, with direct object access (no OOP table) there is a fundamental<br>
problem that makes diff encoding of images almost impossible. If an<br>
object dies, everything after it is compacted and changes its address.<br>
If you have an OOP table, the objects are referenced through something<br>
that is never compacted, but if objects are accessed directly then every<br>
pointer in the image is changing.<br>
</blockquote>
<br>
<br></div>
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 ...</blockquote>
<div><br></div><div>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.</div><div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br><font color="#888888">
<br>
- Bert -<br>
<br>
<br>
<br>
</font></blockquote></div><br></div>