Re: Saxon with GraalVM and native/AOT compilation
Michael Kay <mike-JkSD5nQpfvpWk0Htik3J/[email protected]> Wed, 16 Sep 2020 09:08:32 +0100
| Newsgroups | gmane.text.xml.saxon.help |
|---|---|
| Message-ID | <[email protected]> |
Thanks. Keep the feedbacck coming. We've been thinking of looking at GraalVM as an alternative/replacement to Excelsior JET, but we haven't got very far yet. > > Step 1: – it didn’t like: > > Processor p= new Processor(true); That would almost certainly be because this call involves dynamic loading. The Configuration we instantiate depends on what we're able to load from the classpath. Saxon uses dynamic loading quite a bit internally, though we do have an internal mechanism that says if it's a known Saxon class, load it statically instead. But you'll almost certainly run up against GraalVM's limitations on dynamic loading and reflexion along the journey. 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. > > I don’t have the error message to hand, but was fixed with: > > Processor p= new Processor(new ProfessionalConfiguration()); > > Step 2 – at compile time I got: > > com.oracle.svm.core.util.UserError$UserException: Class initialization of com.saxonica.functions.extfn.SendMail failed. Use the option --initialize-at-run-time=com.saxonica.functions.extfn.SendMail to explicitly request delayed initialization of this class. I'd start with HE code which is going to have far fewer dependencies. > > > Step 3 – then at runtime I see this in the stacktrace: > > at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:193) > Caused by: java.lang.IllegalStateException: Failed to load com.saxonica.xsltextn.style.SaxonElementFactory. Check that saxon9ee.jar is on the classpath > at com.saxonica.config.ProfessionalConfiguration.declareBuiltInExtensionElementNamespaces(ProfessionalConfiguration.java:890) > at com.saxonica.config.ProfessionalConfiguration.<init>(ProfessionalConfiguration.java:142) > at com.deltaxml.json.rest.ComparisonService.<init>(ComparisonService.java:116) > Those line numbers suggest this is Saxon 9.8? The setExtensionElementNamespace() method is doing dynamic loading. Again, doing HE first might be easier. Some of these cases of dynamic loading could easily be dispensed with if necessary, e.g. they could be replaced with edition-dependent preprocessing tags in the source code. > > I could plow on diagnosing/fixing, but each AOT compilation run takes about 20 minutes. Ouch, that's painful! Michael Kay Saxonica _______________________________________________ saxon-help mailing list archived at http://saxon.markmail.org/ [email protected] https://lists.sourceforge.net/lists/listinfo/saxon-help