On Mon, Aug 25, 2003 at 08:13:48PM +0200, Leopold Toetsch wrote: > This patch generates a second vtable (and class enum) for a PMC, when > the pmc class defintions contains C<const_too>. > > To make that actually usable, I'm thinking of: > - the vtable gets a flag for const classes > - pmc_new uses the constant PMC pool, when that flag is set > - but the vtable is first the writeable variant of the $class > - so the PMC can be initialized or filled with data > - then morph() gets called, which sets the real vtable of Const$class > - as this vtable will not contain a usable morph, the PMC stays const > from here on. > - for user code, there is one new opcode needed: > morph in PMC, in INTVAL # morph PMC $1 to type $2 > > Comments welcome,
I'd not thought of doing this sort of thing, but it seems very sensible. It ought to cause constant PMCs to end up grouped close together in memory, so that if a process forks that page should stay shared. (hmm. and the page should stay clean, so the VM system won't need to write it out once its stable) Nicholas Clark
