Hi Sam,
> > Fix initialization of modules in SINGLEMAP_MEMORY model, part 2.
>
> it's weird that you need such an elaborate fix for the problem triggered
> by optimizations.
The commit that you found by bisecting enabled various kinds of optimizations;
in particular it disabled NO_ADDRESS_SPACE_ASSUMPTIONS. This made it possible
to use GENERATIONAL_GC, with either TRIVIALMAP_MEMORY or SINGLEMAP_MEMORY.
On Linux/x86_64, the heuristics choose SINGLEMAP_MEMORY.
SINGLEMAP_MEMORY implies that all objects contain the typecode already in
the address, and that this typecode does not need to be masked out.
But this means that all "preallocated" objects, like the symbols from
constsym.d and the SUBRs need to be allocated in mmap()ed memory.
So, the subr_t records that we build up in subr.d and through the modprep-
generated tables are not used at runtime; they only serve to _initialize_
the subr_t records that are using at runtime.
The F() macro had made an assumption that the subr_t at runtime and the
subr_t that contains its initialization data are identical. This assumption
is no longer generally valid. In fact, the address of a SUBR such as
REGEXP::REGEXP-FREE is no longer predictable: it depends on the number
of SUBRs defined by subr.d and of the number of SUBRs defined by all
prior modules.
So spvw.d has to inform the module about the base address of the SUBRs
of the module. This has to be done in init_function_2 and (maybe -
better safe than sorry) also in init_function_1.
And this means that the default implementation of the init_function_2
is no longer empty. Which required changes to all modules that define
an init_function_2 of their own.
Bruno
|
