On Jan 30, 2006, at 22:00, Nicholas Clark wrote:
On Mon, Jan 30, 2006 at 03:54:51PM +0100, Leopold Toetsch wrote:
I think, we should use the constant table and allow storing into
the constant table.
I don't know the parrot source code well enough to know whether the
constant
table is static const at the C level. (Or capable of being compiled
that way).
No it's not a C static const and it can't be considered a such. It's
built at compile/PBC load time incrementally by appending e.g. doubles
or PMC constants, like subroutine PMC, or STRING constants. A C static
const alike is e.g. used for STRING constants in the source code, via
the CONST_STRING macro.
But my comment is that Jarkko recently put considerable effort into
cleaning
up the Perl 5 core so that as much data as possible was static const,
so that
it facilitated shared library use. (In this case for Symbian)
Good point, albeit it doesn't apply to the thing currently called
constant table.
So I (mis)interpret "storing to the constant table" as "aaargh, can't
be static
const" which feels bad to me. So if the constant table can be static
const,
does this mean that parrot would benefit from a compile time
initialised
constant table, and a "run time" initialised constant table? With your
proposed writable C static variables in the run time initialised table.
The constant table is currently a list of pointers to unions of
'constant' values. It's created when loading a bytecode file (or
equivalently during compile/run cycle). *If* the the constant table
were split into more dedicated parts, a const list of doubles could be
part of the PBC and be considered as read-only/shared because it would
be just mmaped, if possible.
The 'constant' part of the table means for Parrot internals that it
isn't marked being alive by the GC, because these items (STRINGs, PMCs)
in the constant table have a dedicated storage arena, which is only
freed at program end (and possibly with --leak-test enabled).
Nicholas Clark
leo
