[xep-support] 64 bit env

Michael Sulyaev msulyaev at renderx.com
Tue Apr 21 08:22:36 PDT 2009


Curelaru_Cristian at 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 at 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 at 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



More information about the Xep-support mailing list