I've had no success replicating the problem with a simple test case on
another computer. I should be able to try again on the server that's
exhibiting the problem next week. As I said before, though, I don't
think this is a Saxon problem.
On Sat, Feb 20, 2010 at 10:16 AM, Inigo Surguy <inigo.surguy@...> wrote:
> It's repeatable with different source documents, and has happened with
> two different stylesheets. The source documents are fairly simple and
> aren't unusual in any way - 5-20kb, no unusual characters or
> constructs, just standard document-style XML. The stylesheets are
> medium complexity XSLT 2, maybe 500 lines or so. The code is running
> via a servlet inside Tomcat 6.
> The symptoms are that the stylesheet runs successfully to completion,
> and then a few seconds later, once the system is idle, the JIT
> compilation kicks in, and the JVM crashes. My feeling is that the
> only thing that matters about the XML and XSLT is that it's large
> enough or called often enough that startElement is called the
> necessary 10,000 times to trigger JIT compilation.
> The JVM "out of swap space" error isn't a "real" OutOfMemoryError in
> the standard sense that there's no Java heap space left - it indicates
> that the JVM tried to allocate additional memory from the native OS,
> and failed. The amount (indicated in the "requested XXX bytes for
> Chunk::new) varies, but is much bigger than I would expect the JIT
> compiler to need (a suspiciously exact 512MB in the example below,
> which interestingly corresponds to the -Xms512M -Xmx512M startup
> parameters I've used for Tomcat). This is running on a server with
> 1.5GB of memory.
> I haven't yet had a chance to produce a test case for this (the server
> is a client's, and the priority was to stop it crashing), but my
> speculation is that it might be reproducable by processing stylesheets
> until the startElement JIT is triggered, and making sure that the
> server doesn't have sufficient free memory to provide 512MB extra to
> Java. I'll see if I can produce a test, and if I can I'll supply it to
> you and to Sun.
> Ah - an important fact I forgot to mention in the previous email is
> that this is using the server VM, not the client VM.
> On Sat, Feb 20, 2010 at 9:36 AM, Michael Kay <mike@...> wrote:
>> Thanks for the information.
>> When you say this is repeatable, is that with the same source document, or
>> with different source documents?
>> Is there anything unusual about the documents?
>> I installed JDK 1.6.0_18 a few days ago and haven't seen any problems.
>> Michael Kay
>>> -----Original Message-----
>>> From: Inigo Surguy [mailto:inigo.surguy@...]
>>> Sent: 19 February 2010 11:39
>>> To: saxon-help@...
>>> Subject: [saxon] Saxon JVM crash "Out of swap space" OOM
>>> error - withsolution
>>> I've been encountering JVM crash problems with Saxon - the
>>> hs_err file starts with:
>>> "# java.lang.OutOfMemoryError: requested 536870920 bytes for
>>> Chunk::new. Out of swap space?"
>>> and further down:
>>> "Current CompileTask: ...
>>> net.sf.saxon.event.ReceivingContentHandler.startElement ..."
>>> This is repeatable for me, and every time, it's when the JIT
>>> compiler is processing the Saxon startElement method.
>>> This seems like it's a JVM problem rather than a Saxon
>>> problem - there should be no way that Saxon methods should be
>>> able to crash the JVM, and particularly not when they're
>>> being JIT compiled. However, in case any other Saxon users
>>> encounter the same problem, the workaround is to prevent the
>>> startElement method from being JITted:
>>> Use a text editor to create a file "hotspot_compiler" and set
>>> its contents to be the line:
>>> exclude net/sf/saxon/event/ReceivingContentHandler startElement
>>> Edit your JVM startup options to include:
>>> This workaround appears to fix the problem for me.
>>> I haven't tried switching to other JVMs or other versions of
>>> Saxon, but it's reasonably likely that this might make the
>>> problem go away as well.
>>> I'm using JDK 1.6.0_18, 32-bit Windows Server 2003, Saxon 18.104.22.168
>>> Download Intel® Parallel Studio Eval Try the new
>>> software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> saxon-help mailing list archived at
>>> http://saxon.markmail.org/ saxon-help@...