Design Patterns and Collection Classes

Ian Piumarta ian.piumarta at inria.fr
Thu Aug 29 12:51:16 UTC 2002


Tim:
> The instant response from my subconscious (the only part working right
> now, headcold has turned off all higher functions) is that you might
> simply be making use of more _space_ now that you have bigger headers.

Nahr.  (We'll forgive you because you have a headcold. ;)

Stephen:
> Thanks...that must be it.

Skeptical.

> I was thinking that IGC was triggered by
> exceeding an object allocation threshold

Correct.

> but in this case it must be
> getting triggered more often by running low on space...

Nope.  The additional space should make absolutely no difference
whatsoever.  The benchmark in question never gets anywhere remotely
close to running out of memory.

Bob:
> Try changing the allocation threshold and see if that makes any
> difference.

I doubt that this will change anything very much (other than making full
GCs happen more frequently).

Stephen('s original message):
> In the normal vm, I see 1503 IGCs taking 3,308 ms and 9% of the time.
> There are 150 tenures with 10 GCs/tenure.
> In the modified vm, I see 6339 IGCs taking 14,443 ms and 23% of the
> time.  There are 173 tenures with 36 GCs/tenure.

Conclusion: lots more garbage is being created (more IGCs).
                                                                                
> Both VMs seem show the same time (2ms) per GC...so I don't think
> having the extra class header has much of an impact on the marking
> performance.

Correct.  (Although it would be the compaction time that would suffer
more than mark time [most classes being old], very slightly, from
having to copy an extra word around.)

However, the above shows that almost all of the additional garbage is
being collected immediately (the # of GCs/tenure is a lot higher, meaning
each IGC is collecting on average a higher % of objects than before,
meaning that the number of "significant" [w.r.t. the application] objects
created per GC is a lot lower than before).  (If many more objects were
surviving then the IGC time would go up noticably due to the increased
volume of stuff being compacted and/or the # of tenures would be a lot
higher due to the survivor threhold being exceeded much more frequently).

Here's my humble suggestion: verify that you've modified the method

	ObjectMemory>>recycleContextIfPossible: cntxOop

appropriately to compensate for the lack of compact class headers in
your image.

Regards,

Ian





More information about the Squeak-dev mailing list