Unfortunately, this workaround is unacceptable in many deployment
environments. I would thus consider this a showstopping bug for Nashorn,
and I hope it can be escalated.
(I understand that this is not the Nashorn project's "fault," but the
bottom line is that Nashorn cannot be used in long-running production
environments until this is solved.)
On 01/09/2014 05:48 PM, Vladimir Ivanov wrote:
Regarding OOME, it's expected in this situation.
If you look at the end of the log, you'll see a set of consecutive
Full GCs. It means Java heap is almost full and reached it's maximum
size. And application is almost halted - VM collects the whole heap
over and over again (>98% of application running time is spent during
stop-the-world GC).
So, VM decides to preventively throw OOME to avoid further heap
thrashing.
As Marcus already noted, it's caused by increase in dynamic footprint
due to JSR292 switch to LambdaForms in 7u40.
The workaround is to increase maximum heap size.
