[ruby-core:18285] Re: Proposal of GC::Profiler

M. Edward (Ed) Borasky wrote:
> Excellent idea!! Now, can all the other implementers build somethin=
g
> like this? ;)

JRuby already has a full complement of memory profiling tools built i=
n,=20
since the JVM provides them.

=E2=9E=94 jruby -J-verbose:gc -e "while true; x =3D 'foo' + 'bar'; en=
d"
[GC 896K->349K(5056K), 0.0094240 secs]
[GC 1245K->939K(5056K), 0.0182340 secs]
[GC 1835K->1043K(5056K), 0.0063530 secs]
[GC 1939K->1043K(5056K), 0.0013650 secs]
[GC 1939K->1043K(5056K), 0.0015050 secs]
[GC 1939K->1043K(5056K), 0.0003080 secs]
[GC 1939K->1043K(5056K), 0.0003060 secs]
^C

=E2=9E=94 jruby -J-Xrunhprof -e "while true; x =3D 'foo' + 'bar'; end=
"
^CDumping Java heap ... allocation sites ... done.
=E2=9E=94 cat java.hprof.txt
=2E.. (extensive information on live objects and allocation sites eli=
ded)
SITES BEGIN (ordered by live bytes) Wed Aug 13 21:28:10 2008
           percent          live          alloc'ed  stack class
  rank   self  accum     bytes objs     bytes  objs trace name
     1 10.90% 10.90%    301920 6290  24071232 501484 307629=20
org.jruby.RubyString
     2  7.18% 18.08%    198776 4120    198776  4120 300000 char[]
     3  5.45% 23.54%    151056 3147  12035616 250742 307639=20
org.jruby.RubyString
     4  3.64% 27.17%    100736 3148   8023712 250741 307640=20
org.jruby.util.ByteList
     5  3.53% 30.70%     97760 4056     97760  4056 300000 java.lang.=
String
     6  2.73% 33.43%     75552 3148   6017784 250741 307641 byte[]
     7  1.30% 34.74%     36104    1     36104     1 306428 short[]
     8  1.30% 36.04%     36104    1     36104     1 306423 short[]
     9  1.07% 37.11%     29568 1232     33096  1379 302194=20
java.util.concurrent.ConcurrentHashMap$HashEntry
    10  1.00% 38.11%     27632   79     27632    79 300000 byte[]

And there are many others, including heap image-browsing tools, memor=
y=20
leak detectors, and so on. Hopefully any GC-related APIs added to Rub=
y=20
would not depend on specific details of the C implementation, so we=
=20
could simply wrap what's already available. I would venture a guess=
=20
there are more GC and memory-profiling tools available for the JVM th=
an=20
just about any other runtime (not that they're all good, but you get =
the=20
idea).

- Charlie