From bd034b6eb04bd59bf70bcd73f04378dbad822fdb Mon Sep 17 00:00:00 2001
From: Gareth Rees
The LO (Leaf Only) pool class is designed for this +
The LO (Leaf Object) pool class is designed for this use case: blocks allocated from this pool do not move and are never protected, and so may be passed safely to foreign code.
diff --git a/mps/manual/html/guide/debug.html b/mps/manual/html/guide/debug.html index 596a38a6a34..b5ae5914b4c 100644 --- a/mps/manual/html/guide/debug.html +++ b/mps/manual/html/guide/debug.html @@ -69,7 +69,7 @@ other references to that object, or a garbage collection may be delayed. And even if it does die, the space it occupies may not be re-allocated for some time.Compile with debugging information turned on (-g on the GCC or Clang command line).
diff --git a/mps/manual/html/guide/perf.html b/mps/manual/html/guide/perf.html index 3ab085ac9ea..9878a0624d8 100644 --- a/mps/manual/html/guide/perf.html +++ b/mps/manual/html/guide/perf.html @@ -73,11 +73,12 @@ most of the blocks allocated in that generation should be found to be copying them can be avoided entirely). If a generation is collected when its blocks are mostly alive, that is a waste of time. -In the table below I give the execution time of test-leaf.scm in +
In the tables below I give the execution time of test-leaf.scm in the toy Scheme interpreter under different settings for its generation -chain. (This test case allocates millions of small short-lived -objects.) In each case the AMC pool is given a chain with a single -generation with the specified capacity and mortality.
+chain. (This test case allocates hundreds of millions of small +short-lived objects.) +First, the effect of varying the capacity of a chain with a single +generation.
| 100 | 0.80 | -39.9 | +362.6 |
| 200 | 0.80 | -30.2 | +354.9 |
| 400 | 0.80 | -25.5 | +349.7 |
| 800 | 0.80 | -16.3 | +314.4 |
| 1600 | 0.80 | -9.0 | +215.7 |
| 3200 | 0.80 | -5.8 | +94.0 |
| 6400 | -0.20 | -4.2 | -|
| 6400 | -0.40 | -4.1 | -|
| 6400 | -0.60 | -4.1 | -|
| 6400 | 0.80 | -4.1 | -|
| 6400 | -0.99 | -4.2 | +53.5 |
| 12800 | 0.80 | -4.2 | +79.6 |
| 25600 | 0.80 | -5.2 | +77.6 |
This table suggests that:
+Second, the effect of varying the mortality of a chain with a single +generation.
+| Capacity | +Mortality | +Execution time (user+sys) | +
|---|---|---|
| 6400 | +0.20 | +55.4 | +
| 6400 | +0.40 | +54.0 | +
| 6400 | +0.60 | +54.0 | +
| 6400 | +0.80 | +53.5 | +
| 6400 | +0.99 | +54.8 | +
Third, the effect of varying the number of generations (all +generations being identical).
+| Generations | +Capacity | +Mortality | +Execution time (user+sys) | +
|---|---|---|---|
| 1 | +6400 | +0.80 | +53.5 | +
| 2 | +6400 | +0.80 | +42.4 | +
| 3 | +6400 | +0.80 | +42.1 | +
| 4 | +6400 | +0.80 | +42.2 | +
| 5 | +6400 | +0.80 | +42.2 | +
These tables suggest that:
Note
@@ -161,6 +229,109 @@ however: see +Note
+| [1] | (1, 2, 3, 4) With this initial allocation of address space, the test +case failed to run to completion after thousands of seconds +and tens of thousands of garbage collection cycles. |
The lesson here is that the allocation of address space has to be +comfortably larger than the working set of the program.
COBOL was designed by the CODASYL committee in 1959–60 to be a business programming language, and has been extended many -times since. It is still the most widely-used programming -language (in terms of lines of code in use).
+times since. A 1997 Gartner Group report estimated that 80% of +computer software (by count of source lines) was written in +COBOL.Prior to 2002, COBOL had no heap allocation, and did well in its application domain without it. COBOL 2002 has pointers and heap allocation through ALLOCATE and @@ -454,7 +455,8 @@ of weak (hash) tables, which have the unusual feature that their keys and values can be dynamically switched from being strong references to weak references, and vice versa (by assigning to the __mode field of the table’s -metatable).
+metatable). It also supports finalization (by +assigning the __gc field of the object’s metatable).