Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^7: references--hard vs anonymous operational weirdness

by hipowls (Curate)
on Mar 24, 2008 at 10:02 UTC ( [id://675879]=note: print w/replies, xml ) Need Help??


in reply to Re^6: references--hard vs anonymous operational weirdness
in thread references--hard vs anonymous operational weirdness

Thanks for your reply. I now understand where I went wrong. Just to try and reduce the degree of bafflement going round I'll explain my (admittedly erroneous) thinking.

On each iteration of the loop the (simplified) process is

  1. Allocate memory for @array
  2. Initialize @array
  3. Deallocate memory assigned to @array
Note: I am only talking about the memory allocated for @array (the AV struct), not the value of @array (the contents).

A smart compiler can optimize that loop so that the allocation and deallocation of the memory occur outside the loop, that is only once. Based on my observation of the actual memory allocation I had assumed that perl was optimizing the loop in just such a manner.

Perl, however, is not that simple and its loop would be more like
  1. Allocate memory for @array
  2. Initialize @array
  3. Deallocate memory assigned to @array if not referred to else where
I am speculating that means that perl can't decide until runtime if the memory slot can be reused which in turn means the optimization isn't possible, at least in the simplest form and may not be worth the overhead in any case.

So what I was seeing was a chunk of memory deallocated and then an immediate request for a chunk of the same type and the memory manager handed over the chunk just released.

  • Comment on Re^7: references--hard vs anonymous operational weirdness

Replies are listed 'Best First'.
Re^8: references--hard vs anonymous operational weirdness
by ikegami (Patriarch) on Mar 24, 2008 at 18:34 UTC

    On each iteration of the loop the (simplified) process is

    1. Allocate memory for @array
    2. Initialize @array
    3. Deallocate memory assigned to @array

    Well, I don't know what you mean by "Initialize @array", but otherwise, that's the documented behaviour. And in most cases — including the one you called optimized — it's the observable behaviour.

    Perl, however, is not that simple and its loop would be more like

    1. Allocate memory for @array
    2. Initialize @array
    3. Deallocate memory assigned to @array if not referred to else where

    No, that's not what it does. For starters, the @array is never deallocated by the loop (or sub).

    1. Allocate memory for @array if it isn't already allocated. (I don't actually know when this is done. It might be earlier.)
    2. When my is executed, put a directive on the stack to clear/free @array.
    3. On stack unwind, in response to the directive, clear the @array if there are no more references to it. Otherwise, allocate a new @array.

      I was thinking of allocation to be handing over a chunk of raw memory and initialization to be things like setting ref count to 1, the pointer to the contents to NULL or however an empty list is represented and any other bookkeeping. It is possible that these two steps are a single opcode and can't be separated.

      On stack unwind, in response to the directive, clear the @array if there are no more references to it. Otherwise, allocate a new @array.
      Surely allocation of a new array would only be done on entry to the block at the start of each iteration?

      Once more thanks for your time. If you would care to point me to documentation where I can read some more that would be helpful (and spare you more tedious questions;). I am looking for somewhere between perl internals and the source tarball. Even knowing where to start on the source would be useful.

      Just spotted perl -lne 'print if /^[^\/]+\.[ch]\s+/' MANIFEST in perlhack, I guess that's where I start.

        I was thinking of allocation to be handing over a chunk of raw memory and initialization to be things like setting ref count to 1, [...]

        Then allocation and initialization are done by the same function (not opcode). newSV and newAV, for example.

        Surely allocation of a new array would only be done on entry to the block at the start of each iteration?

        No, it's done on exit.

        The directive to which I referred is SAVEt_CLEARSV. It's placed on the stack by SAVECLEARSV. In the code relating to SAVEt_CLEARSV in Perl_leave_scope in scope.c, you'll spot

        switch (SvTYPE(sv)) { /* Console ourselves with a new value */ case SVt_PVAV: *(SV**)ptr = (SV*)newAV(); break; case SVt_PVHV: *(SV**)ptr = (SV*)newHV(); break; default: *(SV**)ptr = newSV(0); break; }

        If you would care to point me to documentation where I can read some more that would be helpful

        I don't know where or if this detail is documented. I discovered it while searching for my's runtime effect.

        perl -MO=Concise -e"code" gives the names of the opcodes (e.g padav for my @array), which you'll find in the pp* files.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://675879]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (3)
As of 2024-04-16 14:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found