[gclist] Page grouping trick
Pekka P. Pirinen
pekka@harlequin.co.uk
Thu, 17 May 2001 19:40:13 +0100
> To my naive eyes it seems this technique could be *very* useful for
> something else - allowing direct addressing along with a fully
> moving collector. Each object could have a permanent address
> composed of virtual page number and offset. On translation this will
> translate to some offset in a physical page. This means we can copy
> objects by copying and re-mapping. Any object lookup will NOT
> require an object table lookup.
I must be missing something: What would be the purpose of this moving?
If the virtual addresses are permanent, your live data will not be
compacted in any useful sense: It's still fragmented and allocating
new objects still requires a free list (of free virtual ranges). So
why did we expend the effort of moving it to different physical pages?
The thing that's different about object tables is that each object, no
matter how large, requires only one slot. I suppose if _all_ your
objects are smaller than a page, you'll get the same simplicity. Then
you hit the hardware limits mentioned.
There is a trick where you copy large objects by choosing a new
virtual address and mapping it onto the old physical address, but
that's the opposite of this one.
--
Pekka P. Pirinen, Harlequin Limited
There may be no candidates you want to vote for, but there are
certainly some you want to vote *against*.