Message-ID: <1256527452.21508.1406823143008.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_21507_1182743212.1406823143008" ------=_Part_21507_1182743212.1406823143008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Well, the most obvious cause of this is memory leaks in your application= But, if you've thoroughly investigated using tools like jconsole, you= rkit, jprofiler or any of the other profiling and analysis tools out there = and you can eliminate your code as the source of the problem, read on.= =20
One symptom of a cluster of jvm related memory issues is the OOM excepti=
on accompanied by a message such as
requested xxxx bytes for xxx. Out of swap space?".
Sun bug number 4697804 descr= ibes how this can happen in the scenario when the garbage collector needs t= o 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 he= ap size to max heap size:=20 =20
Another workaround is to ensure you have configured sufficient swap spac= e on your device to accommodate all programs you are running concurrently.<= /p>=20
Another issue related to jvm bugs is the exhaustion of native memory. Th=
e 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 o=
f things, the JIT compiler being one, and nio ByteBuffers being another. Su=
n bug number 6210541 discusses=
a still-unsolved problem whereby the jvm itself allocates a direct ByteBuf=
fer in some circumstances that is never garbage collected, effectively eati=
ng native memory. Guy Korland's blog discusses this problem here and <=
class=3D"external-link" rel=3D"nofollow">here. As the JIT compiler is =
one consumer of native memory, the lack of available memory may manifest it=
self in the JIT as OutOfMemory exceptions such as
"Exception in =
thread "CompilerThread0" java.lang.OutOfMemoryError: requested xx=
x bytes for ChunkPool::allocate. Out of swap space?"
By default, Jetty will allocate and manage its own pool of direct ByteBu= ffers for io if the nio SelectChannelConnector is configured. It also alloc= ates MappedByteBuffers to memory-map static files via the DefaultServlet se= ttings. However, you could be vulnerable to this jvm ByteBuffer allocation = problem if you have disabled either of these options. For example, if you'r= e on Windows, you may have disabled the use of memory-mapped buffers for th= e static file cache on the DefaultServlet to avoid the file-locking problem.=20
The JSP engine in Jetty is Jasper. This was originally developed under t= he Apache Tomcat project, but over time has been forked by many different p= rojects. All jetty versions up to 6 used Apache-based Jasper exclusively, w= ith Jetty 6 using Apache Jasper only for JSP2.0. With the advent of JSP 2.1= , Jetty 6 switched to using Jasper from Sun's Glassfish proje= ct, which is now the reference implementation.=20
All forks of Jasper suffer from a problem whereby the permgen space can = be put under pressure by using jsp tag files. This is because of the classl= oading architecture of the jsp implementation. Each jsp file is effectively= compiled and its class loaded in its own classloader so as to allow for ho= t replacement. Each jsp that contains references to a tag file will compile= the tag if necessary and then load it using its own classloader. = If you have many jsps that refer to the same tag file, then the tag's class= will be loaded over and over again into permgen space, once for each jsp. = The relevant Glassfish bug report is bug # 3963, and the equival= ent Apache Tomcat bug report is bug # 43878. The Apache Tomcat proj= ect has already closed this bug report with status WON'T FIX, however the G= lassfish folks still have the bug report open and have scheduled it to be f= ixed. When the fix becomes available, the Jetty project will pick it up and= incorporate into our release program.