[% setvar title A proposed internal base format for perl variables %]

This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/


A proposed internal base format for perl variables


  Maintainer: Dan Sugalski <dan@sidhe.org>
  Date: 4 Aug 2000
  Mailing List: perl6-internals@perl.org
  Number: 35
  Version: 1
  Status: Developing


Perl needs to keep track of its data somehow. This is a possible how.


This RFC describes the generic portions of perl's internal data representation. This information is common across all of perl's different data types.

This is similar to the structure used in perl 5, with one major difference. Rather than having all the intellegence needed to use a variable separate from that variable, this RFC embeds that information into the variable itself. This allows for more efficient code to access the vriables, and it lets us add in variable types on the fly. This way perl doesn't, for example, have to know how to access an individual element of an array of integers--it just asks the array to return it a particular element. Code MUST use the vtable functions to get or set values from variables. They MUST NOT directly access the data.

This base structure should be considered immobile, so it's safe to maintain pointers to it. The data portion of a variable should be considered moveable, and may be shuffled around if a variable changes its type, or the garbage collector needs to compact the heap.

Implementation on various types (arrays, hashes, scalars) as well as sub-types (integer scalars, string scalars, objects) is left to another RFC.


The base variable structure looks like:

    struct {
      IV GC_data;
      void *variable_data;
      IV flags;
      void *vtable;
      void *sync_data;

The fields, in order, are:


The sync_data MUST be used properly by perl when safe access to data is needed. What scheme is used to synchronize is not dictated by this RFC. It's assumed that whatever scheme is put in place will perform properly.

For speed and simplicity, the functions in the vtable may assume that proper synchronization has been done on the variable before they have been called, and that they have exclusive and safe access. No synchronization beyond this is guaranteed, so if the vtable functions have extra synchronization needs they are assumed to take care of that themselves.


None. Generally embedding apps won't deal with actual perl data


None. Extensions get pointers to this structure, which as far as they know is a magic cookie. (In fact the official perl term for the thing handed to extensions is a Perl Magic Cookie, or PMC) Knowledge of the internals is a no-no at this level.


Op functions have intimate knowledge of the internals and unrestricted access. Therefore they're assumed to know what they're doing, and will therefore heed the info in this RFC.