[gclist] Page grouping trick
Malcolm Cohen
malcolm@nag.co.uk
Thu, 17 May 2001 10:12:16 +0100 (BST)
John Levon said:
>A set of differing virtual pages could be translated into
>the same physical page, at different offsets (mentioned in "precise access
>barrier with hardware dirty bits" thread and follow-ons).
>
>This would ,for one, allow an object-accurate "card"-marking scheme
>for generational collectors etc. as each virtual dirty bit would refer
>to each object, but each object needn't have a page all on its own.
Well, each object has a virtual page all on its own.
Instead of running out of physical memory you can now run out of virtual
memory (e.g. on a 32-bit system with 4K pages, only 1 million objects
are possible in total, no matter how small).
>The issues raised in the thread were the obvious ones of the overhead of
>a large number of virtual pages in terms of page tables, TLB behaviour etc.
>Can anyone comment further on this ?
Yes, performance will go down the pan if you start thrashing the TLB.
On some systems (e.g. MIPS chips), TLB refills are done in software,
so this is potentially very expensive.
Systems using inverted page tables could get a headache from this approach.
Another potentially serious problem is that munging the virtual address
like this may reduce the entropy therein and therefore increase the
likelihood of cache line conflicts if the cache is based on virtual
addresses.
>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.
Well, you've replaced the object table lookup with a page table lookup.
This should work well while you are operating within the design parameters
of the virtual memory system (which on most systems probably means a small
number of objects), and could perform extremely badly outside those
parameters.
Cheers,
--
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
(malcolm@nag.co.uk)
_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp