www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GC statistics

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
This is mostly for GC experts out there - what statistics are needed and 
useful, yet not too expensive to collect?

https://github.com/D-Programming-Language/druntime/pull/236


Andrei
Oct 10 2012
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 10 October 2012 at 19:35:33 UTC, Andrei 
Alexandrescu wrote:
 This is mostly for GC experts out there - what statistics are 
 needed and useful, yet not too expensive to collect?

 https://github.com/D-Programming-Language/druntime/pull/236


 Andrei

Although I am not a GC expert, have you look at these examples already? http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstat.html http://golang.org/pkg/runtime/#MemStats http://www.haskell.org/ghc/dist/current/docs/html/libraries/base-4.6.0.0/GHC-Stats.html -- Paulo
Oct 10 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 10-10-2012 21:47, Paulo Pinto wrote:
 On Wednesday, 10 October 2012 at 19:35:33 UTC, Andrei Alexandrescu wrote:
 This is mostly for GC experts out there - what statistics are needed
 and useful, yet not too expensive to collect?

 https://github.com/D-Programming-Language/druntime/pull/236


 Andrei

Although I am not a GC expert, have you look at these examples already? http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstat.html

Way too much information to digest in that one. Anything in particular you'd like to see?
 http://golang.org/pkg/runtime/#MemStats

 http://www.haskell.org/ghc/dist/current/docs/html/libraries/base-4.6.0.0/GHC-Stats.html





 --
 Paulo

-- Alex Rønne Petersen alex lycus.org http://lycus.org
Oct 20 2012
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 10/10/2012 21:11, Andrei Alexandrescu a écrit :
 This is mostly for GC experts out there - what statistics are needed and
 useful, yet not too expensive to collect?

 https://github.com/D-Programming-Language/druntime/pull/236


 Andrei

Number of collections (full and young if it is appropriate), maximum time of pause induced, average time of pause. Size of different heap parts if it is appropriate. All are not expansive to compute.
Oct 10 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 10-10-2012 23:19, deadalnix wrote:
 Le 10/10/2012 21:11, Andrei Alexandrescu a écrit :
 This is mostly for GC experts out there - what statistics are needed and
 useful, yet not too expensive to collect?

 https://github.com/D-Programming-Language/druntime/pull/236


 Andrei

Number of collections (full and young if it is appropriate), maximum time of pause induced, average time of pause. Size of different heap parts if it is appropriate.

Can you elaborate on what you'd like to see here?
 All are not expansive to compute.

-- Alex Rønne Petersen alex lycus.org http://lycus.org
Oct 20 2012
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Wed, 10 Oct 2012 20:11:29 +0100, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:
 This is mostly for GC experts out there - what statistics are needed and  
 useful, yet not too expensive to collect?

 https://github.com/D-Programming-Language/druntime/pull/236

I'm no GC expert, but I did just spend almost a week learning how to track down GC/memory related issues in C#. I found the following windows performance counters useful: http://msdn.microsoft.com/en-us/library/x2tyfybc.aspx R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Oct 11 2012
prev sibling next sibling parent reply "dsimcha" <dsimcha yahoo.com> writes:
On Wednesday, 10 October 2012 at 19:35:33 UTC, Andrei 
Alexandrescu wrote:
 This is mostly for GC experts out there - what statistics are 
 needed and useful, yet not too expensive to collect?

 https://github.com/D-Programming-Language/druntime/pull/236


 Andrei

I'd like to see mark, sweep and page-freeing time be counted separately so that if overall GC performance is slow, the user can identify where the bottleneck is. For example, mark time will be slow if there's a lot of total memory to be scanned. Sweep time will be slow if there are a lot of blocks allocated, even if they're all small. I'm not sure if this is feasible, though, because it assumes that the GC implementation is mark-sweep. I guess we could name the subcategories something more generic like mark and process marks.
Oct 11 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 12-10-2012 05:38, dsimcha wrote:
 On Wednesday, 10 October 2012 at 19:35:33 UTC, Andrei Alexandrescu wrote:
 This is mostly for GC experts out there - what statistics are needed
 and useful, yet not too expensive to collect?

 https://github.com/D-Programming-Language/druntime/pull/236


 Andrei

I'd like to see mark, sweep and page-freeing time be counted separately so that if overall GC performance is slow, the user can identify where the bottleneck is. For example, mark time will be slow if there's a lot of total memory to be scanned. Sweep time will be slow if there are a lot of blocks allocated, even if they're all small. I'm not sure if this is feasible, though, because it assumes that the GC implementation is mark-sweep. I guess we could name the subcategories something more generic like mark and process marks.

How do we best represent this in the statistics struct though? Wipe and set on every GC cycle or maintain some sort of average over time? -- Alex Rønne Petersen alex lycus.org http://lycus.org
Oct 20 2012
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 10/10/2012 9:11 PM, Andrei Alexandrescu wrote:
 This is mostly for GC experts out there - what statistics are needed and
 useful, yet not too expensive to collect?

 https://github.com/D-Programming-Language/druntime/pull/236


 Andrei

What about allocation time? Including/excluding possible locks. A precise garbage collector might have to do extra book keeping affecting overall performance. Running this precise GC https://github.com/rainers/druntime/tree/precise_gc2 against the benchmark https://github.com/rainers/druntime/blob/precise_gc2/benchmark/gcbench/tree1.d shows that it is about 20% slower than the conservative GC, most of the extra time eaten during allocation.
Oct 12 2012