Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Small_Object_Pool objects contain pointers to a data structure called a Small_Object_Arena, which is used to demarcate sections of the pool (for what ultimate purpose, however, I am not sure).

    A pool contains a linked list of arenas so that we can allocate or deallocate an arena at a time rather than reallocating a pool at a time.

    I'm never sure how much to explain for everyone else following along, but I like to err on the side of verbosity.

    All of our GCable entities ultimately come out of arenas. A

    • I had actually figured out what the Small_Object_Arena structure was used for after I had written my post. I probably could have posted an addendum or something to explain it.

      Parrot, as a matter of brilliance, doesn't call malloc for every single bit of memory it needs: instead, it allocates memory in large-ish chunks with the intent that those chunks store precisely n objects of size m, as chromatic mentioned. Doing things this way, reducing the number of memory transactions and speculating on future memory needs, helps to increase performance in a major way, and also helps the OS to reduce memory fragmentation.

      As chromatic also mentioned, Parrot does not currently ever return memory to the OS after it has been checked out. I think it is not only feasible, but should be requisite eventually that Parrot does return memory to the OS if it has a surplus and is not using it all. If we do some basic compacting to combine together half-full arenas, we would end up with a large number of arenas that are empty. If we are currently using X arenas, and have a total of Z allocated with Y = Z - X empty arenas, there should be some mathematical relation Y = D X above which we can return some empty arenas back to the system. This is all speculation, at this point. This kind of advanced memory management scheme might be beyond the scope of my GSoC project (although there is no saying I wont be able to implement it after the fact).

      The Parrot memory system, like the rest of it, is very complex. However, the deeper I look, the more obvious it is to me how well thought-out most of it is. There are a precious few small issues that I would change if I could, but none of them are that huge a deal.
      --
      Andrew Whitworth