Nicholas Clark wrote:
On Sat, Aug 20, 2005 at 10:03:50AM -0600, Jim Cromie wrote:
BTW- anyone know how to do this (such that it compiles) ?
#define SIZE_SVTYPES sizeof(sizeof_body_by_svtype)
#define SIZE_OFFSETS sizeof(sizeof_body_by_svtype)
/* they better stay synchronized, but this doesnt do it.
#if SIZE_SVTYPES != SIZE_OFFSETS
#error "declaration problem: sizeof_body_by_svtype !=
sizeof(offset_by_svtype)"
#endif
*/
I don't think it's possible at compile time. The simplest way would seem
to be to compile a small program that #includes sufficient perl headers,
run it (possibly to generate an output file via a Makefile rule) and have
that file, or the successful running of the program as a prerequisite of
compiling the rest of miniperl
ok. I dont want to wrestle with config/make, but if someone JDI,
Ill patch in the bits I want.
ALSO (near the top, so everyone reads it)
please note the comment below. I think Im missing something, perhaps an old
bug / suboptimality.
static int sizeof_body_by_svtype[] = {
0, /* SVt_NULLs, SVt_IVs, SVt_NVs, SVt_RVs have no body */
0,
sizeof(XPVNV), /* 20: seems wrong, but matches old code */
0,
...
Is wrong. NVs (with IVs) were the original allocation hack, where only
sizeof(NV) [or sizeof(IV)] got allocated, but the pointer to the allocated
bit of memory was manipulated downwards, so that it pointed into somewhere
else, but (pointer + structure offset of NV slot) pointed to the allocated
NV-sized piece of memory.
another pointer to ghost memory, used with +tive offset ?
If I leave 0 there (the way I had it 1st), I get a divide by zero, below
the new_XNV() macro.
trying to fix it proper looks to lead to sv_upgrade, I dont want to
tangle with that dragon.
I dont have a backtrace at hand, but can make one if you like.
Is current version close enough to go in, or does this sizeof thing need
a proper fix?
is it as simple as noop'g new_XNV macro ?
And this is probably invasive enough as it is.
Needs a good smoking.
I'd go with that - smoke this first, then see what's next.
Then theres HE and pte arenas, which might fold into the array
( in the unused slots) and possibly even SV-heads themselves (at idx=0,
naturally).
That's interesting. SV heads are different, in that their arena is documented
as carrying allocation flags. Specifically SvFAKE is used to signal that this
arena isn't to be free()d. I 've no idea what uses this - none of the core
seems to.
yeah, SV-heads look too special for next step. But how about HEs next,
and pte's
Are those usages similar enough to fold in easily (later) ?
And IIRC, someone said something about Socket data being allocated in
very large (mostly wasted) chunks. These could probly be handled as 1
more arena
(one of the unused ones)
I was unaware of this.
hmm. I couldnt find it in the code when I looked,
but have the recollection nonetheless.
Too many blue (or was it red?) pills perhaps.
YAGNI ? also possible is tuning arena-size by svtype, possibly w
adjustments
for memory growth during runtime (limited geometric growth). Starting
with small arenas would make them more palatable for the big/rare types.
Not sure if these 'gains' are real/measurable.
I don't know.
Even currently it should be possible to write a module for CPAN that traverses
the SV heads and compacts the allocations of SV bodies.
(Assuming that nothing is evil enough to store a direct pointer to the body)
I'm not sure if we'd benefit from getting much more complex in the arena
allocation code.
yeah - brainstorming is easy, and no code gets hurt.
Nicholas Clark
thx
Jim Cromie
