Odd behaviour of ResizableWhateverArray PMC's

[Christoph Otto]

Martin Kealey wrote:
> I decided that as my first contribution to Parrot I would work on rewriting
> some tests as PIR, especially those for PMC's. First up was
> ResizableIntegerArray, which wasn't too hard, but I noticed some things
> weren't being checked.
> 
> In particular, I noticed that it wasn't checking that expanding the array
> zeroed-out the intermediate values, so I added that check.
> 
> And it failed.
> 
> And thus began a debate: some hold that it's only a "low level buffer" and
> that initialization isn't guaranteed; others (like me) hold that this breaks
> a fairly fundamental guarantee.
> 
> The claim that it's "low level" and therefore it should be "uninitialized
> because it's faster" doesn't fit with it being an arbitrarily resizable (*1)
> array. A primitive operation like "push" can take O(n) time to complete
> because it may result in the entire array being block-copied in memory. So
> complaining about potentially taking O(n) time to arbitrarily resize doesn't
> make sense.
> 
> It's also inconsistent with ResizablePMCArray, ResizableBooleanArray and
> ResizableStringArray, which *do* reinitialize elements when the array is
> resized.
> 
>>From a more pragmatic angle, I doubt that any language implementer will be
> able to use this PMC as-is, and that if they use it at all, they'll either:
> 
> (a) not use the arbitrary resizing, or
> (b) extend the PMC to initialize upon extension.
> 
> Which I guess argues for having *two* core PMC's:
> 
>  * IndexedIntegerQueue -- supports push, pop, shift, unshift, truncate,
>    elements, and maybe even splice, but doesn't support setting an arbitrary
>    length; and
> 
>  * ResizableIntegerArray -- as per current PMC, but with a guarantee
>    that unset elements are always zero.
> 
> Then I looked at ResizableFloatArray; turns out it would fail an equivalent
> test. (Moreover, putting random bits in a FP hardware register can raise
> SIGFPE on some systems, so "low level" really starts to seem out-of-place
> there.)
> 
> I contend that we should extend the current resizable arrays to include
> zeroing out unassigned elements, and if a faster "indexed queue" PMC is
> wanted, it can be built later.
> 
> What does everyone else think?
> 
> -Martin
> 
> (*1: If the only way to extend such an array was by push and unshift, then I
> wouldn't have a problem, because there would be no way to create
> uninitialized cells. Alternatively, if we got rid of all the expensive
> operations -- including push, pop, shift, unshift and delete -- and just
> left a raw buffer, then I'd be happy too, although I'd probably turn around
> and want to build full-feature versions as well.)
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
> 

Welcome to Parrot and thanks for taking the time to look into this issue.

I guess it kinda makes sense to initialize the complex types (STRING and PMC) 
and leave garbage in the primitive types (Integer and Float), but it strikes 
me a premature optimization and hardly ever DTRT.  Since it involves changing 
the smallest amount of code, I'd vote for making RFA and RIA initialize empty 
elements upon resizing.

Christoph