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.