Re^2: Internals question.

taking a reference of an alias of an undefined array value, ...

The fact that they are aliases, nor that the array elements are undefined, seems to have no bearing upon the 'problem' at all:

c:\test>perl -wle"$#a = 10; print \$_ for @a"
SCALAR(0x225138)
SCALAR(0x225120)
SCALAR(0x225144)
SCALAR(0x225168)
SCALAR(0x1824378)
SCALAR(0x224f4c)
SCALAR(0x2250f0)
SCALAR(0x18243cc)
SCALAR(0x18243d8)
SCALAR(0x18243e4)
SCALAR(0x18243f0)

c:\test>perl -wle"@a = 0..10; print \$_, qq[ '$_'] for @a"
SCALAR(0x182bd8c) '0'
SCALAR(0x182bd98) '1'
SCALAR(0x182bda4) '2'
SCALAR(0x182bdb0) '3'
SCALAR(0x182bdbc) '4'
SCALAR(0x182bdc8) '5'
SCALAR(0x182bdd4) '6'
SCALAR(0x224f4c) '7'
SCALAR(0x2250f0) '8'
SCALAR(0x182beb8) '9'
SCALAR(0x182bec4) '10'

c:\test>perl -wle"@a = 0..10; print \$a[ $_ ], qq[ '$a[ $_ ]'] for @a"
SCALAR(0x182bdfc) '0'
SCALAR(0x182be08) '1'
SCALAR(0x182be14) '2'
SCALAR(0x182be20) '3'
SCALAR(0x182be2c) '4'
SCALAR(0x182be38) '5'
SCALAR(0x182be44) '6'
SCALAR(0x224f5c) '7'
SCALAR(0x225100) '8'
SCALAR(0x182bf28) '9'
SCALAR(0x182bf34) '10'
[download]

And indeed, if I try it in a begin block before anyhting has had a chance to be freed, I get exactly what I was expecting, inspite of the aliases to undefined values:

c:\test>perl -wle"BEGIN{ $#a = 10; print \$_ for @a }"
SCALAR(0x182c120)
SCALAR(0x182c114)
SCALAR(0x182c12c)
SCALAR(0x182c138)
SCALAR(0x182c144)
SCALAR(0x182c150)
SCALAR(0x182c15c)
SCALAR(0x182c168)
SCALAR(0x182c174)
SCALAR(0x182c180)
SCALAR(0x182c18c)
[download]

Which pretty much confirms jdporter's view that this is just memory reuse, with the ordering falling out of whatever 'freespace chain mechanism' is used.

But your pointis well taken. Perl doesn't and shouldn't make any guarentees about the relative ordering of the addresses assigned to consecutive SVs in an array. And my hope that I could force Perl to assign consecutive addresses by pre-allocating a large array early in my program was simply naive.

I had hoped that by allocating 'big and early' I could force Perl to go to the OS for more space and so get consecutive addresses--which it does to a degree, in as much as, the xvpav has to be allocated as a contiguous chunk of ram. But the SVs it points to, do not. Combine that with the fact that perl manages memory using multiple different sized pools, and it stands to reason that when it comes to allocating those SVs, any old, freed SVs available will get reused.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re^2: Internals question. Select or Download Code

Replies are listed 'Best First'.
Re^3: Internals question. by shmem (Chancellor) on Jul 23, 2007 at 21:48 UTC
taking a reference of an alias of an undefined array value, ... The fact that they are aliases, nor that the array elements are undefined, seems to have no bearing upon the 'problem' at all: Of course; it's just memory reuse, but I just listed all the facts... ,-) --shmem _($_=" "x(1<<5)."?\n".q·/)Oo. G°\ / /\_¯/(q / ---------------------------- \__(m.====·.(_("always off the crowd"))."· ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}	[reply]

Replies are listed 'Best First'.

Re^3: Internals question.
by shmem (Chancellor) on Jul 23, 2007 at 21:48 UTC

taking a reference of an alias of an undefined array value, ...
The fact that they are aliases, nor that the array elements are undefined, seems to have no bearing upon the 'problem' at all:

Of course; it's just memory reuse, but I just listed all the facts... ,-)

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

[reply]