I’m trying to understand better how the GC works because I cannot derive that from the parameters in the VirtualMachine object in the pharo image.
Can someone sketch the position lifecycle of an object or point me to a document where this is described? Maybe the following questions help in helping.
- object allocation happens in eden space?
- after a few cycles eden space objects are considered survivor. Which is the process for a cycle? incremental GC run?
- survivors are moved to youngSpace? After how many cycles?
- after a few more cycles an object is moved to old space?
- the term tenuring describes the process of moving object from young space to old space or also from eden to young space?
- when is a full GC triggered?
- a full GC is the only process that removes objects from old space?
- the size of eden space and young space are fixed or relative to heap size?
- how big is the initial size of old space when the vm is started?
- if the heap size is not restricted is it likely a full GC happens or does the heap grow indefinite?
- what does the VirtualMachine>>#tenureCount mean? Is the tenuring runs or tenured objects?
Before the list gets to long I stop here. Your answers might remove many of them already.
thanks in advance,
A lot of this changed with the introduction of Spur. See
and then come back with more questions ;)
- Bert -
On Fri 5. Jul 2019 at 00:17, Norbert Hartl <[hidden email]> wrote:
Dr. Bert Freudenberg
7275 Franklin Avenue #210
Los Angeles CA 90046
+1 (818) 482-3991
On Jul 5, 2019, at 10:41 AM, Bert Freudenberg <[hidden email]> wrote:
wot he said. Plus:
and from https://squeak.org/research/ find
And anyway, let me answer inline...
If an object has 254 x pointersize bytes or less it gets allocated in eden. If larger it gets allocated in old space. If there is no space left in old space an allocation will fail, run the GC, retry, and if it fails again, attempt up allocate a large enough new segment in old space to hold the object. See handleFailingBasicNew: et al.
In the old system this is indeed an incremental GC run. In Spur it is a scavenge. Spur uses a straightforward implementation of David Ungar’s Generation Scavenger to reclaim most young objects. The scavenger is extended with Ungar & Jackson’s adaptive tenuring policy and with support for weak arrays and ephemerons. See
And the code in VMMaker.oscog in SpurGenerationScavenger is by far the most readable scavenging code I’ve seen beyond Ungar’s pseudo-code (the Spur code being more complex due to weakness & ephemeron support).
Survivors are moved to old space once the adaptive tenuring policy decides they should be. In good times objects will not be tenured ever (ie if scavenging frees lots of objects to make space in eden for new ones). But if scavenging fails to make space available bad times are entered and older objects will get tenured (the order of objects in new space reflects their age since allocation proceeds up through eden and since traversal of objects during scavenging is breadth first so the order of objects in a survivor space also reflects their age).
Only from new space (eden + the survivor spaces) to old space.
Under two circumstances. One, automatically, when old space grows by a ratio its previous size at the last GC. See vm parameterAt: 55. The other, explicitly under image control, typically when a large allocation fails, but also explicitly under programmer control.
Fixed, determined at startup and/or stored in the image header (see vm parameterAt: 6, 19, 45, 67), with default sizes depending on the pointer size, 4mb for 32 bits & 7mb for 64 bits.
As big as the image plus one empty segment.
The old space growth ratio policy described above runs the GC automatically, but this isn’t a good idea when the image is growing due to eg reading in lots of data. So changing the ratio while in a growth phase is a good idea. I believe there is a convenience method for doing this that raises the ratio very high while running a block.
Number of tenured objects.
|Free forum by Nabble||Edit this page|