X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=pod%2Fperlintern.pod;h=41ddbbad37d02cc2fd5a956a1065070193191c01;hb=d44161bfbb2e964e9675634d6bf5e566d1d1d4f7;hp=c9cb5e76985ee3c22438d084500e5724139d5862;hpb=a4f1a0295dfc0733a51ca0623d486d082d04773a;p=p5sagit%2Fp5-mst-13.2.git

diff --git a/pod/perlintern.pod b/pod/perlintern.pod
index c9cb5e7..41ddbba 100644
--- a/pod/perlintern.pod
+++ b/pod/perlintern.pod
@@ -11,6 +11,293 @@ format but are not marked as part of the Perl API. In other words,
 B<they are not for use in extensions>!
 
 
+=head1 CV reference counts and CvOUTSIDE
+
+=over 8
+
+=item CvWEAKOUTSIDE
+
+Each CV has a pointer, C<CvOUTSIDE()>, to its lexically enclosing
+CV (if any). Because pointers to anonymous sub prototypes are
+stored in C<&> pad slots, it is a possible to get a circular reference,
+with the parent pointing to the child and vice-versa. To avoid the
+ensuing memory leak, we do not increment the reference count of the CV
+pointed to by C<CvOUTSIDE> in the I<one specific instance> that the parent
+has a C<&> pad slot pointing back to us. In this case, we set the
+C<CvWEAKOUTSIDE> flag in the child. This allows us to determine under what
+circumstances we should decrement the refcount of the parent when freeing
+the child.
+
+There is a further complication with non-closure anonymous subs (ie those
+that do not refer to any lexicals outside that sub). In this case, the
+anonymous prototype is shared rather than being cloned. This has the
+consequence that the parent may be freed while there are still active
+children, eg
+
+    BEGIN { $a = sub { eval '$x' } }
+
+In this case, the BEGIN is freed immediately after execution since there
+are no active references to it: the anon sub prototype has
+C<CvWEAKOUTSIDE> set since it's not a closure, and $a points to the same
+CV, so it doesn't contribute to BEGIN's refcount either.  When $a is
+executed, the C<eval '$x'> causes the chain of C<CvOUTSIDE>s to be followed,
+and the freed BEGIN is accessed.
+
+To avoid this, whenever a CV and its associated pad is freed, any
+C<&> entries in the pad are explicitly removed from the pad, and if the
+refcount of the pointed-to anon sub is still positive, then that
+child's C<CvOUTSIDE> is set to point to its grandparent. This will only
+occur in the single specific case of a non-closure anon prototype
+having one or more active references (such as C<$a> above).
+
+One other thing to consider is that a CV may be merely undefined
+rather than freed, eg C<undef &foo>. In this case, its refcount may
+not have reached zero, but we still delete its pad and its C<CvROOT> etc.
+Since various children may still have their C<CvOUTSIDE> pointing at this
+undefined CV, we keep its own C<CvOUTSIDE> for the time being, so that
+the chain of lexical scopes is unbroken. For example, the following
+should print 123:
+
+    my $x = 123;
+    sub tmp { sub { eval '$x' } }
+    my $a = tmp();
+    undef &tmp;
+    print  $a->();
+
+	bool	CvWEAKOUTSIDE(CV *cv)
+
+=for hackers
+Found in file cv.h
+
+
+=back
+
+=head1 Functions in file pad.h
+
+
+=over 8
+
+=item CX_CURPAD_SAVE
+
+Save the current pad in the given context block structure.
+
+	void	CX_CURPAD_SAVE(struct context)
+
+=for hackers
+Found in file pad.h
+
+=item CX_CURPAD_SV
+
+Access the SV at offset po in the saved current pad in the given
+context block structure (can be used as an lvalue).
+
+	SV *	CX_CURPAD_SV(struct context, PADOFFSET po)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_BASE_SV	
+
+Get the value from slot C<po> in the base (DEPTH=1) pad of a padlist
+
+	SV *	PAD_BASE_SV	(PADLIST padlist, PADOFFSET po)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_CLONE_VARS
+
+|CLONE_PARAMS* param
+Clone the state variables associated with running and compiling pads.
+
+	void	PAD_CLONE_VARS(PerlInterpreter *proto_perl \)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_COMPNAME_FLAGS
+
+Return the flags for the current compiling pad name
+at offset C<po>. Assumes a valid slot entry.
+
+	U32	PAD_COMPNAME_FLAGS(PADOFFSET po)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_COMPNAME_GEN
+
+The generation number of the name at offset C<po> in the current
+compiling pad (lvalue). Note that C<SvCUR> is hijacked for this purpose.
+
+	STRLEN	PAD_COMPNAME_GEN(PADOFFSET po)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_COMPNAME_OURSTASH
+
+Return the stash associated with an C<our> variable.
+Assumes the slot entry is a valid C<our> lexical.
+
+	HV *	PAD_COMPNAME_OURSTASH(PADOFFSET po)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_COMPNAME_PV
+
+Return the name of the current compiling pad name
+at offset C<po>. Assumes a valid slot entry.
+
+	char *	PAD_COMPNAME_PV(PADOFFSET po)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_COMPNAME_TYPE
+
+Return the type (stash) of the current compiling pad name at offset
+C<po>. Must be a valid name. Returns null if not typed.
+
+	HV *	PAD_COMPNAME_TYPE(PADOFFSET po)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_DUP
+
+Clone a padlist.
+
+	void	PAD_DUP(PADLIST dstpad, PADLIST srcpad, CLONE_PARAMS* param)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_RESTORE_LOCAL
+
+Restore the old pad saved into the local variable opad by PAD_SAVE_LOCAL()
+
+	void	PAD_RESTORE_LOCAL(PAD *opad)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_SAVE_LOCAL
+
+Save the current pad to the local variable opad, then make the
+current pad equal to npad
+
+	void	PAD_SAVE_LOCAL(PAD *opad, PAD *npad)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_SAVE_SETNULLPAD
+
+Save the current pad then set it to null.
+
+	void	PAD_SAVE_SETNULLPAD()
+
+=for hackers
+Found in file pad.h
+
+=item PAD_SETSV	
+
+Set the slot at offset C<po> in the current pad to C<sv>
+
+	SV *	PAD_SETSV	(PADOFFSET po, SV* sv)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_SET_CUR	
+
+Set the current pad to be pad C<n> in the padlist, saving
+the previous current pad.
+
+	void	PAD_SET_CUR	(PADLIST padlist, I32 n)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_SV	
+
+Get the value at offset C<po> in the current pad
+
+	void	PAD_SV	(PADOFFSET po)
+
+=for hackers
+Found in file pad.h
+
+=item PAD_SVl	
+
+Lightweight and lvalue version of C<PAD_SV>.
+Get or set the value at offset C<po> in the current pad.
+Unlike C<PAD_SV>, does not print diagnostics with -DX.
+For internal use only.
+
+	SV *	PAD_SVl	(PADOFFSET po)
+
+=for hackers
+Found in file pad.h
+
+=item SAVECLEARSV	
+
+Clear the pointed to pad value on scope exit. (ie the runtime action of 'my')
+
+	void	SAVECLEARSV	(SV **svp)
+
+=for hackers
+Found in file pad.h
+
+=item SAVECOMPPAD
+
+save PL_comppad and PL_curpad
+
+
+
+
+
+	void	SAVECOMPPAD()
+
+=for hackers
+Found in file pad.h
+
+=item SAVEPADSV	
+
+Save a pad slot (used to restore after an iteration)
+
+XXX DAPM it would make more sense to make the arg a PADOFFSET
+	void	SAVEPADSV	(PADOFFSET po)
+
+=for hackers
+Found in file pad.h
+
+
+=back
+
+=head1 Functions in file pp_ctl.c
+
+
+=over 8
+
+=item find_runcv
+
+Locate the CV corresponding to the currently executing sub or eval.
+If db_seqp is non_null, skip CVs that are in the DB package and populate
+*db_seqp with the cop sequence number at the point that the DB:: code was
+entered. (allows debuggers to eval in the scope of the breakpoint rather
+than in in the scope of the debuger itself).
+
+	CV*	find_runcv(U32 *db_seqp)
+
+=for hackers
+Found in file pp_ctl.c
+
+
+=back
+
 =head1 Global Variables
 
 =over 8
@@ -141,14 +428,15 @@ CV's can have CvPADLIST(cv) set to point to an AV.
 
 For these purposes "forms" are a kind-of CV, eval""s are too (except they're
 not callable at will and are always thrown away after the eval"" is done
-executing).
+executing). Require'd files are simply evals without any outer lexical
+scope.
 
 XSUBs don't have CvPADLIST set - dXSTARG fetches values from PL_curpad,
 but that is really the callers pad (a slot of which is allocated by
 every entersub).
 
 The CvPADLIST AV has does not have AvREAL set, so REFCNT of component items
-is managed "manual" (mostly in op.c) rather than normal av.c rules.
+is managed "manual" (mostly in pad.c) rather than normal av.c rules.
 The items in the AV are not SVs as for a normal AV, but other AVs:
 
 0'th Entry of the CvPADLIST is an AV which represents the "names" or rather
@@ -160,11 +448,14 @@ The 0'th slot of a frame AV is an AV which is @_.
 other entries are storage for variables and op targets.
 
 During compilation:
-C<PL_comppad_name> is set the the the names AV.
-C<PL_comppad> is set the the frame AV for the frame CvDEPTH == 1.
-C<PL_curpad> is set the body of the frame AV (i.e. AvARRAY(PL_comppad)).
+C<PL_comppad_name> is set to the names AV.
+C<PL_comppad> is set to the frame AV for the frame CvDEPTH == 1.
+C<PL_curpad> is set to the body of the frame AV (i.e. AvARRAY(PL_comppad)).
+
+During execution, C<PL_comppad> and C<PL_curpad> refer to the live
+frame of the currently executing sub.
 
-Itterating over the names AV itterates over all possible pad
+Iterating over the names AV iterates over all possible pad
 items. Pad slots that are SVs_PADTMP (targets/GVs/constants) end up having
 &PL_sv_undef "names" (see pad_alloc()).
 
@@ -177,21 +468,280 @@ but only by their index allocated at compile time (which is usually
 in PL_op->op_targ), wasting a name SV for them doesn't make sense.
 
 The SVs in the names AV have their PV being the name of the variable.
-NV+1..IV inclusive is a range of cop_seq numbers for which the name is valid.
-For typed lexicals name SV is SVt_PVMG and SvSTASH points at the type.
-
-If SvFAKE is set on the name SV then slot in the frame AVs are
-a REFCNT'ed references to a lexical from "outside".
-
-If the 'name' is '&' the the corresponding entry in frame AV
+NV+1..IV inclusive is a range of cop_seq numbers for which the name is
+valid.  For typed lexicals name SV is SVt_PVMG and SvSTASH points at the
+type.  For C<our> lexicals, the type is SVt_PVGV, and GvSTASH points at the
+stash of the associated global (so that duplicate C<our> delarations in the
+same package can be detected).  SvCUR is sometimes hijacked to
+store the generation number during compilation.
+
+If SvFAKE is set on the name SV, then that slot in the frame AV is
+a REFCNT'ed reference to a lexical from "outside". In this case,
+the name SV does not use NVX and IVX to store a cop_seq range, since it is
+in scope throughout. Instead IVX stores some flags containing info about
+the real lexical (is it declared in an anon, and is it capable of being
+instantiated multiple times?), and for fake ANONs, NVX contains the index
+within the parent's pad where the lexical's value is stored, to make
+cloning quicker.
+
+If the 'name' is '&' the corresponding entry in frame AV
 is a CV representing a possible closure.
 (SvFAKE and name of '&' is not a meaningful combination currently but could
 become so if C<my sub foo {}> is implemented.)
 
+Note that formats are treated as anon subs, and are cloned each time
+write is called (if necessary).
+
 	AV *	CvPADLIST(CV *cv)
 
 =for hackers
-Found in file cv.h
+Found in file pad.c
+
+=item cv_clone
+
+Clone a CV: make a new CV which points to the same code etc, but which
+has a newly-created pad built by copying the prototype pad and capturing
+any outer lexicals.
+
+	CV*	cv_clone(CV* proto)
+
+=for hackers
+Found in file pad.c
+
+=item cv_dump
+
+dump the contents of a CV
+
+	void	cv_dump(CV *cv, char *title)
+
+=for hackers
+Found in file pad.c
+
+=item do_dump_pad
+
+Dump the contents of a padlist
+
+	void	do_dump_pad(I32 level, PerlIO *file, PADLIST *padlist, int full)
+
+=for hackers
+Found in file pad.c
+
+=item intro_my
+
+"Introduce" my variables to visible status.
+
+	U32	intro_my()
+
+=for hackers
+Found in file pad.c
+
+=item pad_add_anon
+
+Add an anon code entry to the current compiling pad
+
+	PADOFFSET	pad_add_anon(SV* sv, OPCODE op_type)
+
+=for hackers
+Found in file pad.c
+
+=item pad_add_name
+
+Create a new name and associated PADMY SV in the current pad; return the
+offset.
+If C<typestash> is valid, the name is for a typed lexical; set the
+name's stash to that value.
+If C<ourstash> is valid, it's an our lexical, set the name's
+GvSTASH to that value
+
+If fake, it means we're cloning an existing entry
+
+	PADOFFSET	pad_add_name(char *name, HV* typestash, HV* ourstash, bool clone)
+
+=for hackers
+Found in file pad.c
+
+=item pad_alloc
+
+Allocate a new my or tmp pad entry. For a my, simply push a null SV onto
+the end of PL_comppad, but for a tmp, scan the pad from PL_padix upwards
+for a slot which has no name and and no active value.
+
+	PADOFFSET	pad_alloc(I32 optype, U32 tmptype)
+
+=for hackers
+Found in file pad.c
+
+=item pad_block_start
+
+Update the pad compilation state variables on entry to a new block
+
+	void	pad_block_start(int full)
+
+=for hackers
+Found in file pad.c
+
+=item pad_check_dup
+
+Check for duplicate declarations: report any of:
+     * a my in the current scope with the same name;
+     * an our (anywhere in the pad) with the same name and the same stash
+       as C<ourstash>
+C<is_our> indicates that the name to check is an 'our' declaration
+
+	void	pad_check_dup(char* name, bool is_our, HV* ourstash)
+
+=for hackers
+Found in file pad.c
+
+=item pad_findlex
+
+Find a named lexical anywhere in a chain of nested pads. Add fake entries
+in the inner pads if it's found in an outer one.
+
+Returns the offset in the bottom pad of the lex or the fake lex.
+cv is the CV in which to start the search, and seq is the current cop_seq
+to match against. If warn is true, print appropriate warnings.  The out_*
+vars return values, and so are pointers to where the returned values
+should be stored. out_capture, if non-null, requests that the innermost
+instance of the lexical is captured; out_name_sv is set to the innermost
+matched namesv or fake namesv; out_flags returns the flags normally
+associated with the IVX field of a fake namesv.
+
+Note that pad_findlex() is recursive; it recurses up the chain of CVs,
+then comes back down, adding fake entries as it goes. It has to be this way
+because fake namesvs in anon protoypes have to store in NVX the index into
+the parent pad.
+
+	PADOFFSET	pad_findlex(char *name, CV* cv, U32 seq, int warn, SV** out_capture, SV** out_name_sv, int *out_flags)
+
+=for hackers
+Found in file pad.c
+
+=item pad_findmy
+
+Given a lexical name, try to find its offset, first in the current pad,
+or failing that, in the pads of any lexically enclosing subs (including
+the complications introduced by eval). If the name is found in an outer pad,
+then a fake entry is added to the current pad.
+Returns the offset in the current pad, or NOT_IN_PAD on failure.
+
+	PADOFFSET	pad_findmy(char* name)
+
+=for hackers
+Found in file pad.c
+
+=item pad_fixup_inner_anons
+
+For any anon CVs in the pad, change CvOUTSIDE of that CV from
+old_cv to new_cv if necessary. Needed when a newly-compiled CV has to be
+moved to a pre-existing CV struct.
+
+	void	pad_fixup_inner_anons(PADLIST *padlist, CV *old_cv, CV *new_cv)
+
+=for hackers
+Found in file pad.c
+
+=item pad_free
+
+Free the SV at offet po in the current pad.
+
+	void	pad_free(PADOFFSET po)
+
+=for hackers
+Found in file pad.c
+
+=item pad_leavemy
+
+Cleanup at end of scope during compilation: set the max seq number for
+lexicals in this scope and warn of any lexicals that never got introduced.
+
+	void	pad_leavemy()
+
+=for hackers
+Found in file pad.c
+
+=item pad_new
+
+Create a new compiling padlist, saving and updating the various global
+vars at the same time as creating the pad itself. The following flags
+can be OR'ed together:
+
+    padnew_CLONE	this pad is for a cloned CV
+    padnew_SAVE		save old globals
+    padnew_SAVESUB	also save extra stuff for start of sub
+
+	PADLIST*	pad_new(int flags)
+
+=for hackers
+Found in file pad.c
+
+=item pad_push
+
+Push a new pad frame onto the padlist, unless there's already a pad at
+this depth, in which case don't bother creating a new one.
+If has_args is true, give the new pad an @_ in slot zero.
+
+	void	pad_push(PADLIST *padlist, int depth, int has_args)
+
+=for hackers
+Found in file pad.c
+
+=item pad_reset
+
+Mark all the current temporaries for reuse
+
+	void	pad_reset()
+
+=for hackers
+Found in file pad.c
+
+=item pad_setsv
+
+Set the entry at offset po in the current pad to sv.
+Use the macro PAD_SETSV() rather than calling this function directly.
+
+	void	pad_setsv(PADOFFSET po, SV* sv)
+
+=for hackers
+Found in file pad.c
+
+=item pad_swipe
+
+Abandon the tmp in the current pad at offset po and replace with a
+new one.
+
+	void	pad_swipe(PADOFFSET po, bool refadjust)
+
+=for hackers
+Found in file pad.c
+
+=item pad_tidy
+
+Tidy up a pad after we've finished compiling it:
+    * remove most stuff from the pads of anonsub prototypes;
+    * give it a @_;
+    * mark tmps as such.
+
+	void	pad_tidy(padtidy_type type)
+
+=for hackers
+Found in file pad.c
+
+=item pad_undef
+
+Free the padlist associated with a CV.
+If parts of it happen to be current, we null the relevant
+PL_*pad* global vars so that we don't have any dangling references left.
+We also repoint the CvOUTSIDE of any about-to-be-orphaned
+inner subs to the outer of this cv.
+
+(This function should really be called pad_free, but the name was already
+taken)
+
+	void	pad_undef(CV* cv)
+
+=for hackers
+Found in file pad.c
 
 
 =back