Re: [xep-support] 64 bit env

From: Michael Sulyaev <msulyaev@renderx.com>
Date: Tue Apr 21 2009 - 08:22:36 PDT

Curelaru_Cristian@emc.com wrote:
> I was wondering if somebody ran tests with RenderX in 64 bit
> environments. Is it supported - not just to run but to take advantage of
> the 64-bit performance?

Hello Cristian,

We know it works. Whether or not it takes advantage of the 64 bit
architecture is rather a question to Java implementation, than to XEP.
XEP is Java 1.3 compliant (well, most of it). In general, there is
nothing to change in Java code to exploit the 64 bit advantages: it is
the responsibility of the runtime. There are no 64 bit long calculations
in XEP. However, XEP uses the heap intensively, so you are likely to
meet the disadvantages of longer GC runs.

> I have a sample that has around 8200 files (dita and images together)
> which fails on 32-bit environments with OutOfMemory exception. The FO
> file that goes into XEP is 300M.

The task is large. A few thoughts here that may help:
   disable validation (after stylesheets are prooved to be bug free in
terms of FO produced);
   disable SUPPORT_XSL11 (or apply it as a separate step);
   feed XEP with pure FO, not with XML+XSL, for memory requirements of
XSLT processor highly depend on the stylesheet, and are effectively
added to those of XEP if running XML+XSL->PDF.
   if many different SVG images are used, consider the new option in
4.15 to avoid memleak in caches.

> We decided to test the same on a 64-bit environment.
>
> This system is windows 2003 enterprise 64-bit, it has on it a java 1.5
> 64-bit and around 18G mem. I started the same test but it has been
> running for a few days now. There is no outofmem error this time, but I
> have observed the Renderx process is not using more than 4.2G of
> physical memory (the theoretical limit of 32 bit) and it takes the rest
> from the page file. There are ~ 13G mem available at all times.

Hmm... I thought Java heap may never go to swap.

> So, any reason why xep would fail to use more physical memory or is it a
> know issues or this was never tested?

No ideas at the moment. Probably, it just does not need more, if it does
not fire OOMs, and is quite satisfied with small and rare GC runs. I'd
appreciate if you send a short sample data and describe which places
should be altered to generate 300Mb sample (to support@renderx.com).
Then I'll be able to run tests in our environments.

Regards,
Michael Sulyaev
RenderX

-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html
Received on Tue Apr 21 08:51:21 2009

This archive was generated by hypermail 2.1.8 : Tue Apr 21 2009 - 08:51:28 PDT