MBeans added...some metrics

[Charles Oliver Nutter-2]

I added over the past couple days a few MBeans to allow monitoring some
of JRuby's internals. I also added a --manage flag that turns on the
remote bits of JMX monitoring so you can connect to the process using
jconsole. All fun stuff.

So here's a few findings from running Rails in normal mode with a bunch
of ab requests (i.e. not handling sessions in any reasonable way):

(this is all jitted...I'll try a +C run after I add monitoring to
on-load compilation.)

dev mode, after startup:

- 69 methods have jitted
- average jitted code size is 3936 bytes
- average compile time is 2300 microseconds (need to doublecheck this
metric...)
- all methods that attempted to JIT have succeeded.
- 11858 call sites have inline cached
- module inclusion has triggered 38 removals, for a total of 88 removals
(very good considering 11858 caches)

after one request to static main page + dynamic info page:

- 75 methods have jitted
- average jitted code size is 3878 bytes
- average compile time is 2171 microseconds
- all methods that attempted to JIT have succeeded
- 14191 call sites have inline cached
- module inclusion has triggered 38 removals, for a total of 89 removals

after 51 requests to the static page and 51 requests to the dynamic page

- 461 methods have jitted (3 reused, which means at least 3 methods that
would otherwise have jitted in a *single* app had identical ASTs)
- average jitted code size is 4024 (1.87MB total byte[], which
translates to somewhat less actual memory used)
- average compile time is 1236microseconds
- all 464 methods that attempted to jit have succeeded (3 reusing code
already jitted)
- 30941 call sites have inline cached, same module/removal statistics

So a few interesting details from this..

- up to this point we're only using about 10% of the current "max"
number of JITted methods. Granted, this is a very simple request, so
maybe that's a high percentage.
- jitted code size isn't too bad considering the number. An LRU that
ages out old, unused methods might be even better.
- 30941 call sites have attempted to cache, but we have no measurement
on how many of those call sites have given up because of too-polymorphic
calls or how many of them might be stepping on each other forcing a
re-cache. Currently the call sites are set to give up after 50 cache
misses. I'll try to add some monitoring for call site caches soon. So busy.

Interesting though.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email