[svn:parrot-pdd] r35571 - in trunk: docs/pdds include/parrot src src/gc src/pmc
Author: Whiteknight Date: Wed Jan 14 16:44:41 2009 New Revision: 35571 Modified: trunk/docs/pdds/pdd09_gc.pod Changes in other areas also in this revision: Modified: trunk/include/parrot/pobj.h trunk/src/gc/generational_ms.c trunk/src/inter_call.c trunk/src/pmc/deleg_pmc.pmc Log: [Core] remove the last few mentions of PObj_data_is_PMC_array_FLAG, and fix an error that I apparently uncovered when I ran make headerizer last time. My bad. Modified: trunk/docs/pdds/pdd09_gc.pod == --- trunk/docs/pdds/pdd09_gc.pod(original) +++ trunk/docs/pdds/pdd09_gc.podWed Jan 14 16:44:41 2009 @@ -576,11 +576,6 @@ PMCs) that PMC refers to. This flag is typically tested and the custom mark VTABLE method called from Csrc/gc/api.c:mark_special. -=item PObj_data_is_PMC_array_FLAG - -Set if the data pointer points to an array of objects. The length of the -array is CPMC_int_val(SELF). - =item PObj_external_FLAG Set if the buffer points to memory that came from outside Parrot's memory
[svn:parrot-pdd] r34246 - trunk/docs/pdds
Author: Whiteknight Date: Mon Dec 22 07:27:08 2008 New Revision: 34246 Modified: trunk/docs/pdds/pdd19_pir.pod trunk/docs/pdds/pdd21_namespaces.pod Log: [PDD] add mention of parrot root namespace to PDD19 and 21. This is for TT#80, which I will close if there are no objections to this edit. Modified: trunk/docs/pdds/pdd19_pir.pod == --- trunk/docs/pdds/pdd19_pir.pod (original) +++ trunk/docs/pdds/pdd19_pir.pod Mon Dec 22 07:27:08 2008 @@ -321,8 +321,8 @@ =item .HLL hll_name -Define the HLL for the current file. Takes one string constant, the name -of the HLL. +Define the HLL namespace for the current file. Takes one string constant, +the name of the HLL. By default, the HLL namespace is 'parrot'. =item .HLL_map core_type = user_type Modified: trunk/docs/pdds/pdd21_namespaces.pod == --- trunk/docs/pdds/pdd21_namespaces.pod(original) +++ trunk/docs/pdds/pdd21_namespaces.podMon Dec 22 07:27:08 2008 @@ -84,6 +84,8 @@ $P0 = get_root_namespace +This root namespace is called C'parrot'. + =item HLL Root Namespaces Each HLL must store public items in a namespace named with the lowercased
[svn:parrot-pdd] r32010 - trunk/docs/pdds
Author: Whiteknight Date: Sat Oct 18 07:21:18 2008 New Revision: 32010 Modified: trunk/docs/pdds/pdd20_lexical_vars.pod Log: [PDDs] Codingstd fix on PDD20, fixing very long lines. Modified: trunk/docs/pdds/pdd20_lexical_vars.pod == --- trunk/docs/pdds/pdd20_lexical_vars.pod (original) +++ trunk/docs/pdds/pdd20_lexical_vars.pod Sat Oct 18 07:21:18 2008 @@ -350,8 +350,8 @@ Here, C$P1 contains information on the current subroutine. C$P2 will contain C$P1's outer subroutine. -To get C$P2's outer subroutine (if any), the same method can be used on C$P2 -itself: +To get C$P2's outer subroutine (if any), the same method can be used on +C$P2 itself: $P3 = $P2.get_outer() @@ -360,7 +360,8 @@ $P0 = getinterp $P1 = $P0[outer; sub] -$P2 = $P0[outer; sub; 2] # get the outer sub of the current's outer subroutine +$P2 = $P0[outer; sub; 2] # get the outer sub of the current's outer + # subroutine It is also possible to get the C:outer sub's LexPad, as above:
[svn:parrot-pdd] r32003 - trunk/docs/pdds
Author: Whiteknight Date: Fri Oct 17 08:37:04 2008 New Revision: 32003 Modified: trunk/docs/pdds/pdd20_lexical_vars.pod Log: [PDD] Add information about get_outer opcode to PDD20. Patch courtesy kjs++ from RT#39615 Modified: trunk/docs/pdds/pdd20_lexical_vars.pod == --- trunk/docs/pdds/pdd20_lexical_vars.pod (original) +++ trunk/docs/pdds/pdd20_lexical_vars.pod Fri Oct 17 08:37:04 2008 @@ -341,13 +341,40 @@ $P0 = getinterp $P1 = $P0[lexpad; 1] +To access a sub's C:outer subroutine, use the Cget_outer() method: + +.include interpinfo.pasm +interpinfo $P1, .INTERPINFO_CURRENT_SUB +$P2 = $P1.get_outer() + +Here, C$P1 contains information on the current subroutine. C$P2 will +contain C$P1's outer subroutine. + +To get C$P2's outer subroutine (if any), the same method can be used on C$P2 +itself: + +$P3 = $P2.get_outer() + + +Using the Cinterpinfo instruction is one way to do it. Another way is this: + +$P0 = getinterp +$P1 = $P0[outer; sub] +$P2 = $P0[outer; sub; 2] # get the outer sub of the current's outer subroutine + +It is also possible to get the C:outer sub's LexPad, as above: + +$P0 = getinterp +$P1 = $P0[outer; lexpad] + +See [1] for an example. + It's likely that this interface will continue to be available even once call frames become visible as PMCs. -=head1 IMPLEMENTATION - TODO: Full interpreter introspection interface. + =head1 ATTACHMENTS None. @@ -358,7 +385,13 @@ =head1 REFERENCES -None. +=over 4 + +=item [1] + +t/op/lexicals.t + +=back =cut
[svn:parrot-pdd] r31995 - trunk/docs/pdds
Author: Whiteknight Date: Thu Oct 16 10:42:15 2008 New Revision: 31995 Modified: trunk/docs/pdds/pdd19_pir.pod Log: [PDD] Add some more information about :unique_reg as per the discussion at RT#57636. Modified: trunk/docs/pdds/pdd19_pir.pod == --- trunk/docs/pdds/pdd19_pir.pod (original) +++ trunk/docs/pdds/pdd19_pir.pod Thu Oct 16 10:42:15 2008 @@ -229,7 +229,22 @@ The optional C:unique_reg modifier will force the register allocator to associate the identifier with a unique register for the duration of the -subroutine. +subroutine. If the register allocator is thought of as an optimization +tool for allowing fewer registers to be used in a register frame by reusing +unused registers, then the C:unique_reg directive forces this +optimization to be turned off. This can be important in a number of +situations: + +=over 4 + +=item* When a subroutine has a small fixed number of registers + +=item* When a named variable or named register is used throughout the entire +subroutine + +=item* When a reference needs to be made to a register + +=back =item .lex string constant, reg
[svn:parrot-pdd] r30604 - in trunk: docs/pdds/draft src
Author: Whiteknight Date: Wed Aug 27 16:25:00 2008 New Revision: 30604 Modified: trunk/docs/pdds/draft/pdd11_extending.pod Changes in other areas also in this revision: Modified: trunk/src/extend.c trunk/src/inter_run.c Log: [DOCS] Document Parrot_call_method as per RT#36243. Also, document a function that is a dependency of this one. Modified: trunk/docs/pdds/draft/pdd11_extending.pod == --- trunk/docs/pdds/draft/pdd11_extending.pod (original) +++ trunk/docs/pdds/draft/pdd11_extending.pod Wed Aug 27 16:25:00 2008 @@ -283,11 +283,13 @@ up Parrot's registers in line with the Parrot calling conventions; see Lpdd03_calling_conventions.pod for more details. -=item CParrot_call_method(interp, -Parrot_PMC sub, Parrot_String method, Parrot_Int argcount, ...) +=item CParrot_call_method(PARROT_INTERP, Parrot_PMC sub, Parrot_PMC obj, +Parrot_String method, ARGIN(const char *signature), ...) -Calls a Parrot method named Cmethod with Cargcount PMC parameters. NB. -This is not yet implemented and may change. +Call the parrot subroutine Csub as a method on PMC object Cobj. The method +should have the name Cmethod as a Parrot_string, and should have a function +signature Csignature. Any arguments to the method can be passed at the end +as a variadic argument list. =back
[svn:parrot-pdd] r30315 - trunk/docs/pdds
Author: Whiteknight Date: Mon Aug 18 16:36:57 2008 New Revision: 30315 Modified: trunk/docs/pdds/pdd09_gc.pod Log: [PDD] a few clarifications to PDD09, some better wording, spelling fixes. Expand on some topics that didn't have great coverage before. Modified: trunk/docs/pdds/pdd09_gc.pod == --- trunk/docs/pdds/pdd09_gc.pod(original) +++ trunk/docs/pdds/pdd09_gc.podMon Aug 18 16:36:57 2008 @@ -377,7 +377,7 @@ Trigger or perform a GC run. With an incremental GC core, this may only start/continue a partial mark phase or sweep phase, rather than performing an entire run from start to finish. It may take several calls to Cdo_gc_mark in -order to complete an entire incremental run. +order to complete an entire run of an incremental collector. For a concurrent collector, calls to this function may activate a concurrent collection thread or, if such a thread is already running, do nothing at all. @@ -432,17 +432,20 @@ =item Cvoid (*finalize_gc_system) (Interp *) Called during interpreter destruction. Free used resources and memory pools. +All PMCs must be swept, and PMCs with custom destroy VTABLE methods must have +those called. =item Cvoid (*init_pool) (Interp *, Small_Object_Pool *) -Initialize the given pool. This function should set the following function -pointers for use with the pool. +Initialize the given pool. Populates the CSmall_Object_Pool structure with +initial values, and sets a series of function pointers for working with the +pool. The function pointers used with the pool are discussed next. =back =head3 Small_Object_Pool function pointers -Each GC core defines 4 function pointers stored in the Small_Object_Pool +Each GC core defines 4 function pointers stored in the CSmall_Object_Pool structures. These function pointers are used throughout Parrot to implement basic behaviors for the pool. @@ -458,7 +461,10 @@ =item Cvoid (*add_free_object) (Interp *, Small_Object_Pool *, PObj *); -Add a freed object to the pool's free list. +Add a freed object to the pool's free list. This function is most often called +internally to the GC itself to add items to the free list after a sweep, or +when a new arena is created to add the new items to the free list. It does +not need to be used in this way, however. =item Cvoid (*alloc_objects) (Interp *, Small_Object_Pool *); @@ -471,93 +477,104 @@ Reallocation for additional objects. It has the same signature as Calloc_objects, and in some GC cores the same function pointer is used for both. In some GC cores, Cmore_objects may do a GC run in an attempt to free -existing objects without having to allocate new ones. +existing objects without having to allocate new ones. This function may also +call Cpool-alloc_objects internally, to allocate objects if a GC run fails +to free any old objects. =back =head3 Write Barrier -Each GC core has to provide these (possibly empty) macros: +Each GC core has to provide the following macros. All of these might be +defined empty, for GC cores which do not use them. =over 4 =item CGC_WRITE_BARRIER(Interp *, PMC *agg, PMC *old, PMC *new) This macro is invoked when in aggregate Cagg the element Cold is getting -overritten by Cnew. Both Cold and Cnew may be NULL. +overwritten by Cnew. Either Cold, Cnew, or both may be NULL. =item CGC_WRITE_BARRIER_KEY(Interp *, PMC *agg, PMC *old, PObj *old_key, PMC *new, PObj *new_key) -Like above. Invoked when a hash key is inserted, possibly replacing an old -key. +Similar to CGC_WRITE_BARRIER. Invoked when a hash key Cnew_key is +inserted into hash Cagg with value Cnew, possibly replacing a key/value +pair Cold_key and Cold, respectively. Any of Cold, Cold_key, Cnew +or Cnew_key might be CNULL. =back =head2 Blocking GC Being able to block GC is important, so newly allocated Buffers or PMCs won't -be collected before they're attached to the live tree. The following -routines control GC: +be collected before they're attached to the live tree. Parrot provides locking +mechanisms to prevent the GC from taking certain actions, such as marking +or sweeping. GC block functions are nesting, and multiple calls to a lock +function requires the same number of calls to the corresponding unlock +function in order to operate the GC normally again. The following functions +are used to block the GC from performing certain actions: =over 4 =item Parrot_block_GC_mark(Interp *interpreter) -Block the GC mark phase for the passed interpreter. (But not the sweep phase) +Block the GC mark phase for the passed interpreter, but do not block the sweep +phase. In a stop-the-world collector, this will prevent the entire collection +run, but in an incremental collector this will only block if the GC is in the +trace state. =item Parrot_block_GC_sweep(Interp *interpreter) -Block the GC sweep phase for the passed interpreter. (But not the mark
[svn:parrot-pdd] r30278 - trunk/docs/pdds
Author: Whiteknight Date: Sun Aug 17 07:55:32 2008 New Revision: 30278 Modified: trunk/docs/pdds/pdd09_gc.pod Log: [GC] Remove mention of GC_no_trace_volatile_roots from PDD09 and include/parrot/dod.h. The flag is not used anywhere in Parrot, and is not documented well enough to be implemented at a later time. Modified: trunk/docs/pdds/pdd09_gc.pod == --- trunk/docs/pdds/pdd09_gc.pod(original) +++ trunk/docs/pdds/pdd09_gc.podSun Aug 17 07:55:32 2008 @@ -427,10 +427,6 @@ get called. PMCs which have custom destructors rely on this behavior for proper operation. -=item GC_no_trace_volatile_roots - -Trace root set except volatile roots. That is skip e.g. registers. - =back =item Cvoid (*finalize_gc_system) (Interp *)
[svn:parrot-pdd] r30011 - trunk/docs/pdds
Author: Whiteknight Date: Mon Aug 4 15:10:22 2008 New Revision: 30011 Modified: trunk/docs/pdds/pdd09_gc.pod Log: [docs/pdd] update pdd09 to include more descriptions, more information and some much-needed clarity. These are all lessons i've learned the hard way. Modified: trunk/docs/pdds/pdd09_gc.pod == --- trunk/docs/pdds/pdd09_gc.pod(original) +++ trunk/docs/pdds/pdd09_gc.podMon Aug 4 15:10:22 2008 @@ -161,6 +161,15 @@ The primary GC model for PMCs, at least for the 1.0 release, will use a tri-color incremental marking scheme, combined with a concurrent sweep scheme. +=head2 Terminology + +A GC run is composed of two distinct operations: Finding objects which are +dead (the trace phase) and freeing dead objects for later reuse (the +sweep phase). The sweep phase is also known as the collection phase. The +trace phase is also known as the mark phase and less frequently as the +dead object detection phase. The use of the term dead object detection +and it's acronym DOD has been deprecated. + =head2 Initial Marking Each PMC has a Cflags member which, among other things, facilitates garbage @@ -186,7 +195,7 @@ =item Global stash -=item System stack +=item System stack and processor registers =item Current PMC register set @@ -335,9 +344,9 @@ =head3 Initialization -Each GC core declares an initialization routine, which is called from -Fsrc/memory.c:mem_setup_allocator() after creating Carena_base in the -interpreter struct. +Each GC core declares an initialization routine as a function pointer, +which is installed in Fsrc/memory.c:mem_setup_allocator() after +creating Carena_base in the interpreter struct. =over 4 @@ -357,40 +366,66 @@ =over 4 +=item Cvoid (*init_gc_system) (Interp *) + +Initialize the GC system. Install the additional function pointers into +the Arenas structure, and prepare any private storage to be used by +the GC in the Arenas-gc_private field. + =item Cvoid (*do_gc_mark) (Interp *, int flags) Trigger or perform a GC run. With an incremental GC core, this may only -start/continue a partial mark phase, rather than marking the entire tree of -live objects. +start/continue a partial mark phase or sweep phase, rather than performing an +entire run from start to finish. It may take several calls to Cdo_gc_mark in +order to complete an entire incremental run. + +For a concurrent collector, calls to this function may activate a concurrent +collection thread or, if such a thread is already running, do nothing at all. -Flags is one of: +The Cdo_gc_mark function is called from the CParrot_do_dod_run function, +and should not usually be called directly. + +Cflags is one of: =over 4 +=item C0 + +Run the GC normally, including the trace and the sweep phases, if applicable. +Incremental GCs will likely only run one portion of the complete GC run, and +repeated calls would be required for a complete run. A complete trace of all +system areas is not required. + =item GC_trace_normal | GC_trace_stack_FLAG -Run a normal GC cycle. This is normally called by resource shortage in the -buffer memory pools before a collection is run. The bit named -CGC_trace_stack_FLAG indicates that the C-stack (and other system areas -like the processor registers) have to be traced too. - -The implementation might or might not actually run a full GC cycle. If an -incremental GC system just finished the mark phase, it would do nothing. OTOH -if no objects are currently marked live, the implementation should run the -mark phase, so that copying of dead objects is avoided. +Run a normal GC trace cycle, at least. This is typically called when there +is a resource shortage in the buffer memory pools before the sweep phase is +run. The processor registers and any other system areas have to be traced too. + +Behavior is determined by the GC implementation, and might or might not +actually run a full GC cycle. If the system is an incremental GC, it might +do nothing depending on the current state of the GC. In an incremental GC, if +the GC is already past the trace phase it may opt to do nothing and return +immediately. A copying collector may choose to run a mark phase if it hasn't +yet, to prevent the unnecessary copying of dead objects later on. =item GC_lazy_FLAG Do a timely destruction run. The goal is either to detect all objects that -need timely destruction or to do a full collection. In the former case the -collection can be interrupted or postponed. This is called from the Parrot -run-loop. No system areas have to be traced. +need timely destruction or to do a full collection. This is called from the +Parrot run-loop, typically when a lexical scope is exited and the local +variables in that scope need to be cleaned up. Many types of PMC objects, such +as line-buffered IO PMCs rely on this behavior for proper operation. + +No system areas have to be traced. =item
[svn:parrot-pdd] r28280 - in trunk: compilers/imcc docs/book docs/pdds include/parrot languages/dotnet/pmc languages/lua/src/pmc src src/gc src/io src/ops src/pmc src/stm t/src
Author: Whiteknight
Date: Thu Jun 12 12:34:51 2008
New Revision: 28280
Modified:
trunk/docs/pdds/pdd09_gc.pod
Changes in other areas also in this revision:
Modified:
trunk/compilers/imcc/main.c
trunk/compilers/imcc/parser_util.c
trunk/docs/book/ch02_getting_started.pod
trunk/include/parrot/dod.h
trunk/include/parrot/oo.h
trunk/include/parrot/resources.h
trunk/languages/dotnet/pmc/dotnetassembly.pmc
trunk/languages/lua/src/pmc/lua.pmc
trunk/languages/lua/src/pmc/luatable.pmc
trunk/src/dynext.c
trunk/src/exit.c
trunk/src/gc/dod.c
trunk/src/gc/gc_gms.c
trunk/src/gc/gc_ims.c
trunk/src/gc/resources.c
trunk/src/gc/smallobject.c
trunk/src/global.c
trunk/src/hash.c
trunk/src/inter_create.c
trunk/src/io/io.c
trunk/src/list.c
trunk/src/ops/core.ops
trunk/src/packfile.c
trunk/src/pbc_merge.c
trunk/src/pdb.c
trunk/src/pmc.c
trunk/src/pmc/continuation.pmc
trunk/src/pmc/default.pmc
trunk/src/pmc/eval.pmc
trunk/src/pmc/fixedpmcarray.pmc
trunk/src/pmc/fixedstringarray.pmc
trunk/src/pmc/parrotinterpreter.pmc
trunk/src/pmc/parrotthread.pmc
trunk/src/pmc/ref.pmc
trunk/src/pmc/resizablepmcarray.pmc
trunk/src/pmc/resizablestringarray.pmc
trunk/src/pmc/sarray.pmc
trunk/src/pmc/tqueue.pmc
trunk/src/pmc_freeze.c
trunk/src/stm/backend.c
trunk/src/string.c
trunk/src/sub.c
trunk/src/thread.c
trunk/t/src/extend.t
Log:
[pdd09] updating function and macro names to satisfy pdd09 deprecation notes.
rt#55364
Modified: trunk/docs/pdds/pdd09_gc.pod
==
--- trunk/docs/pdds/pdd09_gc.pod(original)
+++ trunk/docs/pdds/pdd09_gc.podThu Jun 12 12:34:51 2008
@@ -194,8 +194,6 @@
=item PMC register stack
-=item General/User stack
-
=back
=head2 Incremental Marking
@@ -230,8 +228,6 @@
=item String register set stack
-=item General/User stack
-
=item Control stack
=back
@@ -367,8 +363,6 @@
start/continue a partial mark phase, rather than marking the entire tree of
live objects.
-{{DEPRECATION NOTE: do_gc_mark used to be do_dod_run.}}.
-
Flags is one of:
=over 4
@@ -385,9 +379,6 @@
if no objects are currently marked live, the implementation should run the
mark phase, so that copying of dead objects is avoided.
-{{DEPRECATION NOTE: GC_trace_normal used to be DOD_trace_normal.
-GC_trace_stack_FLAG used to be DOD_trace_stack_FLAG.}}
-
=item GC_lazy_FLAG
Do a timely destruction run. The goal is either to detect all objects that
@@ -395,32 +386,22 @@
collection can be interrupted or postponed. This is called from the Parrot
run-loop. No system areas have to be traced.
-{{DEPRECATION NOTE: GC_lazy_FLAG used to be DOD_lazy_FLAG.}}
-
=item GC_finish_FLAG
Called during interpreter destruction. The GC subsystem must clear the live
state of all objects and perform a sweep in the PMC header pool, so that
destructors and finalizers get called.
-{{DEPRECATION NOTE: GC_finish_FLAG used to be DOD_finish_FLAG.}}
-
=item GC_no_trace_volatile_roots
Trace root set except volatile roots. That is skip e.g. registers.
-{{DEPRECATION NOTE: GC_no_trace_volatile_roots used to be
-DOD_no_trace_volatile_roots.}}
-
=back
=item Cvoid (*finalize_gc_system) (Interp *)
Called during interpreter destruction. Free used resources and memory pools.
-{{DEPRECATION NOTE: finalize_gc_system used to be
-de_init_gc_system.}}
-
=item Cvoid (*init_pool) (Interp *, Small_Object_Pool *)
A function to initialize the given pool. This function should set the
@@ -470,16 +451,12 @@
This macro is invoked when in aggregate Cagg the element Cold is getting
overritten by Cnew. Both Cold and Cnew may be NULL.
-{{DEPRECATION NOTE: used to be DOD_WRITE_BARRIER.}}
-
=item CGC_WRITE_BARRIER_KEY(Interp *, PMC *agg, PMC *old, PObj
*old_key, PMC *new, PObj *new_key)
Like above. Invoked when a hash key is inserted, possibly replacing an old
key.
-{{DEPRECATION NOTE: used to be DOD_WRITE_BARRIER_KEY.}}
-
=back
=head2 Blocking GC
@@ -494,27 +471,27 @@
Block the GC mark phase for the passed interpreter. (But not the sweep phase)
-{{DEPRECATION NOTE: used to be Parrot_block_DOD.}}
-
=item Parrot_block_GC_sweep(Interp *interpreter)
Block the GC sweep phase for the passed interpreter. (But not the mark phase)
-{{DEPRECATION NOTE: used to be Parrot_block_GC.}}
-
=item Parrot_unblock_GC_mark(Interp *interpreter)
Unblock the GC mark phase for the passed interpreter. (But not the sweep
phase)
-{{DEPRECATION NOTE: used to be Parrot_unblock_DOD.}}
-
=item Parrot_unblock_GC_sweep(Interp *interpreter)
Unblock the GC sweep phase for the passed interpreter. (But not the mark
phase)
-{{DEPRECATION NOTE: used to be Parrot_unblock_GC.}}
+=item Parrot_is_blocked_GC_mark(Interp *interpreter)
+
+Test whether the mark phase has been blocked.
+
+=item Parrot_is_blocked_GC_sweep(Interp *interpreter)
+
+Test
