Smalltalk › Squeak › Squeak VM

Explanation of GC behaviour

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 3 messages Options
NorbertHartl
Reply | Threaded
Open this post in threaded view
♦
♦
|

Explanation of GC behaviour

NorbertHartl
 
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,

Norbert
Bert Freudenberg
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Explanation of GC behaviour

Bert Freudenberg
 
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:
 
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,

Norbert
--
-- 
Dr. Bert Freudenberg
7275 Franklin Avenue #210
Los Angeles CA 90046
+1 (818) 482-3991
 
Eliot Miranda-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Explanation of GC behaviour

Eliot Miranda-2
 


On Jul 5, 2019, at 10:41 AM, Bert Freudenberg <[hidden email]> wrote:

A lot of this changed with the introduction of Spur. See 

wot he said.  Plus:


  1. Sophie Kaleba, Clément Béra, and Eliot Miranda. “Garbage Collection Evaluation Infrastructure for the Cog VM.” In International Workshop on Smalltalk Technologies, 2018.
  2. Eliot Miranda and Clément Béra. “A Partial Read Barrier for Efficient Support of Live Object-Oriented Programming.” In Proceedings of the Symposium on Memory Management (ISMM) 2015, 93–104, 2015. http://doi.acm.org/10.1145/2754169.2754186.
And anyway, let me answer inline...


- Bert -

On Fri 5. Jul 2019 at 00:17, Norbert Hartl <[hidden email]> wrote:
 
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?

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.

- after a few cycles eden space objects are considered survivor. Which is the process for a cycle? incremental GC run?

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 youngSpace? After how many cycles?

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).

- after a few more cycles an object is moved to old space?

See above.

- the term tenuring describes the process of moving object from young space to old space or also from eden to young space?

Only from new space (eden + the survivor spaces) to old space.

- when is a full GC triggered?

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.

- a full GC is the only process that removes objects from old space?

Yes.

- the size of eden space and young space are fixed or relative to heap size?

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.

- how big is the initial size of old space when the vm is started?

As big as the image plus one empty segment.

- if the heap size is not restricted is it likely a full GC happens or does the heap grow indefinite?

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.

- what does the VirtualMachine>>#tenureCount mean? Is the tenuring runs or tenured objects?

Number of tenured objects.


Before the list gets to long I stop here. Your answers might remove many of them already.

thanks in advance,

Norbert
--
-- 
Dr. Bert Freudenberg
7275 Franklin Avenue #210
Los Angeles CA 90046
+1 (818) 482-3991
 
Free forum by Nabble Edit this page