JBossDeveloper

Hi Rajiv,

I have raised and fixed BYTEMAN-36, adding a new cache for ClassChecker instances to the master and 3.X branches.

I also added an option to trace cache puts and cache hits, enabling stats to be gathered (set -D org.jboss.byteman.checker.dumpstats=true on the command line to enable tracing).  I tested this using Wildlfy 10 with one overriding CLASS rule and one overriding interface rule and it was very successful in reducing lookups. Here are the rules (they are defined never to actually generate a match):

RULE test
INTERFACE Foo
METHOD foo
AT ENTRY
IF TRUE
DO traceln("Foo.foo()");
ENDRULE

RULE test2
CLASS Bar
METHOD bar
AT ENTRY
IF TRUE
DO traceln("Bar.bar()");
ENDRULE

The final counts printed after Widlfly startup are

  maps 100 classes 1532 bytes 1792904 hits 3202 hit bytes 1982611

i.e. lookups occurred from 100 different classloaders for 1532 classes (that includes some repeated lookup of the same super/interface from different starting loader). The number of resource bytes loaded was 1792904 and the number of extra bytes that would have been loaded without the cache was 1982611.

I also collected and analysed the names of the classes associated with each Put an Hit listed in the trace output:

Total Puts:  1532
Total Hits:  3202
Unique Puts: 1072
Unique Hits:  425

The first thing to note is that the hit rate is just over 2 Hits per Put which matches the byte load savings.

The ratio of Total Puts to Unique Puts indicates that there are quite a few cases where a super or interface is looked up from subclasses that belong to different loaders (on average 1 out of every 2 classes but actually there is quiet a small number of classes that have many lookups). That figure would have been quite a bit higher without a trick I worked out. Classes whose name starts with "java." can only ever be loaded via the bootstrap loader. So, for that case I always look up the checker or, failing that, the class bytes resource using the bootstrap loader. So, there is only 1 Put and many Hits for java.lang.Serializable, java.lang.Runnable, java.util.Collection etc. Without this trick these classes get anywhere from 15 to 60 puts in as many different loader maps.

The ratio of Unique Hits to Total Hist is quite high. That's doesn't indicate that the cache is not working. On the contrary, it's merely a reflection of the fact that many classes get looked up multiple times from the same class loader as well as occasionally from a different class loader.

Anyway, the acid test is startup times. Without the cache the above two rules added about 1 sec to startup time. With the cache the additional time is around 100 msecs. So, this is indeed a big win, as expected. I hope it

I have deployed a new 4.0.3-SNAPSHOT build to the maven central repo. I hope it helps improve your startup. Let me know if you have any further problems.

regards,

Andrew Dinn

Hi Rajiv,

Thanks for the feedback. I am on holiday for 2 weeks from noon on Thursday. I wlll try to get a new release out before then.

regards,

Andrew Dinn

Hi Rajiv,

Byteman 4.0.3 and 3.0.13 are now released.

regards,

Andrew Dinn