Steve Fink wrote:
On Jan-01, Leopold Toetsch wrote:
I know, that things get worse with optimization and with more complex programs.
And with other architectures that make heavier use of registers -- i386 may be an unrealistic example, since not much can even fit into the available register set.
Yep. The goal can only be, to either have *all* code paths that might trigger DOD checked, or use one of the mentioned strategies. Though reducing possibilities of infant mortatility by early anchoring is IMHO always a good thing: it would e.g. help active pinning.
The clone functions could be redone like:
Parrot_do_dod_run(); // get free headers if possible
Parrot_block_DOD/GC();
do_clone
Parrot_unblock_DOD/GC
This would also be faster, because there are no DOD runs during clone (which wouldn't yield more free headers anyway).
But wouldn't that force a DOD run on every clone? Normally, DOD should be extremely rare compared to clones.
With above code yes. But classes can estimate, how much resources would be needed to e.g. clone a PerlArray of 100 elements. When the needed header count is far beyond the allocation of HEADERS_PER_ALLOC above strategy is a win. Cloning small aggregates or scalars could be done without explicit Parrot_do_dod_run when there are enough headers on the free list.
So we would have additionally something like:
if (pmc->vtable->needed_headers_for_clone() > pmc_pool->replenish_level)
do_dod_run()
eventually checking other pools to, which is a lot cheaper then, e.g. 100 unnecessary DOD runs during cloning a huge array.
leo
