Jetty has moved!
Jetty is a project at the Eclipse Foundation.
Homepage:http://www.eclipse.org/jetty
Downloads: http://download.eclipse.org/jetty/
Documentation:http://www.eclipse.org/jetty/documentation/current/
About:http://www.eclipse.org/jetty/about.php
Jetty Powered:http://www.eclipse.org/jetty/powered/
Contact the core Jetty developers at www.webtide.com
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

OutOfMemory Errors

Well, the most obvious cause of this is memory leaks in your application (smile) But, if you've thoroughly investigated using tools like jconsole, yourkit, jprofiler or any of the other profiling and analysis tools out there and you can eliminate your code as the source of the problem, it may be due to bug(s) in the JVM.

One symptom of a cluster of jvm related memory issues is the OOM exception accompanied by a message such as "java.lang.OutOfMemoryError: requested xxxx bytes for xxx. Out of swap space?".

Sun bug number 4697804 describes how this can happen in the scenario when the garbage collector needs to allocate a bit more space during its run and tries to resize the heap but fails because the machine is out of swap space. One suggested work around is to ensure that the jvm never tries to resize the heap, by setting min heap size to max heap size:

Another workaround is to ensure you have configured sufficient swap space on your device to accommodate all programs you are running concurrently.

Another issue related to jvm bugs is the exhaustion of native memory. The symptoms to look out for are the process size growing, but the heap usage remaining relatively constant. Native memory can be consumed by a number of things, the JIT compiler being one, and nio ByteBuffers being another. Sun bug number 6210541 discusses a still-unsolved problem where the jvm allocates a direct ByteBuffer in some circumstances that is never garbage collected, effectively eating native memory. Guy Korland's blog discusses this problem here and here. As the JIT compiler is one consumer of native memory, the lack of available memory may manifest itself in the JIT as OutOfMemory exceptions such as "Exception in thread "CompilerThread0" java.lang.OutOfMemoryError: requested xxx bytes for ChunkPool::allocate. Out of swap space?"

By default, Jetty will allocate and manage its own direct ByteBuffers for io if the nio SelectChannelConnector is configured, and MappedByteBuffers to memory-map static files. However, you could be vulnerable to the jvm ByteBuffer allocation problem if you have disabled either of these options. For example, if you're on Windows, you may have disabled the memory-mapped buffers for the static file cache to avoid the file-locking problem.

  • No labels
Contact the core Jetty developers at www.webtide.com
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery