Re: Saxon with GraalVM and native/AOT compilation

Hi Mike – thanks for the feedback and advice.

Note that Saxon does all (hopefully?) its dynamic loading via its own DynamicLoader class, which you can substitute using Configuration.setDynamicLoader(), and writing a substitute DynamicLoader implementation for this environment might be a sensible way forward. In fact, without using GraalVM at all, you might write a diagnostic version of the class just to see what calls are being made.

Thanks – I’ll give that a go.

I'd start with HE code which is going to have far fewer dependencies.

In order to simplify the problem and speed up the compile it would make sense to break it up into smaller components.  I’m thinking of taking HE and building a simple REST service that does an XSLT transformation and AOTing that.
I suspect that will give us much more representative (of Saxon and our code too)  numbers on startup time improvements.


Those line numbers suggest this is Saxon 9.8?

Yes it was, but only because that’s what the build I branched from was configured to use.  I’ll use 10.2 HE for a performance PoC.


I could plow on diagnosing/fixing, but each AOT compilation run takes about 20 minutes.

Ouch, that's painful!

It also needs about 20 GB of RAM.  One issue on macOS is that it fires up Docker in order to run the build in a Linux container.  I needed to do a fair bit of config to give Docker enough resources to get the first pass working.

Thanks for the help,  I’ll hopefully be reporting back with numbers soon.

Nigel

--
Nigel Whitaker, DeltaXML Ltd, Malvern Hills Science Park, WR14 3SZ, UK.  Regisered in England 02528681

_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[email protected]
https://lists.sourceforge.net/lists/listinfo/saxon-help