Duplicate :
|
|
Duplicate :
|
|
Relates :
|
An iPlanet app has encountered huge minor pause times (40+sec) due to oopmap generation by the interpreter. More generally, some oopmap generations are observed to take >200ms, which is more than the entire GC budget for the Nortel telco application. Oopmaps are needed for interpreted frames. We have interpreted frames when the compiler bails out. Some of the bailing methods are code generated from JSPs, that have heavy nesting of try..finally. Both c1 and c2 are bailing out in this particular case. Fixing compiler bailouts in general is a large project. One might automagically refactor large methods instead, which would also be a large project. Oopmaps tell, for a particular bci, whether each slot holds an oop. The current system caches this information. Normally one hopes that methods are compiled, and thus no longer need oopmaps. However, the same methods that cause compiler bailouts are also causing unexpectedly large oopmap generation times, occasionally on the order of 100s of msec. The offending code does fixed-point data flow iteration. Simply growing the cache size doesn't help, because there are a very large number of possible bci's in these large methods. Changing the way JSPs generate code may help avoid bailouts, but won't fix the underlying problem.
|