Bug: :flat and :slurpy don't mix

-- Bob Rogers
http://rgrjr.dyndns.org/

argument, parrot r10337 just hangs, chewing up CPU time . . .

Turns out this is because of "premature optimization" -- and all
flattening is affected, depending only on the PMC class of the :flat
array, and not whether there is a :slurpy parameter (hence another test
case). When starting to flatten, st->src.slurp_n is initialized with a
result from a hacked version of VTABLE_elements, which could return
garbage (i.e. something that looks like a PMC *). If a PerlArray is
being flattened, then the parrot_pass_args loop attempts to copy 1e8 or
so Undef values to an insatiable destination array, leading to the
appearance of an unbounded loop. I changed the array class in the new
test cases to a plain Array, which will die much sooner with an "out of
bounds" error if this should ever regress. TIA,

Argh - sorry. That shouldn't have been on of course. I did some
benchmarking and must have forgotten to disable it. It is ment to
access the signature array faster. The type of the signature array is
known as Parrot is constructing it. The flatten code must of course be
outside the range of this define.

Thanks a lot for spotting this and the tests, applied - r10385.

leo

Make sense. Thanks for explaining.

But it's not clear to me that it would ever be worth optimizing
VTABLE_elements calls, even for the signature array. Seems to me that
it's called exactly twice per call/return sequence, true?

leo

No problem; glad to be useful. If I get a chance, I'll try to work up
more call/return tests involving :slurpy and/or :flat.

-- Bob