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
