Saxon » SaxonC

Update on memory usage issues:

I have been doing some extensive work on the performance testing of Saxon-C. This stems from our comparison work to other XSLT implementations from different platforms. This is inline with the project https://github.com/Saxonica/XT-Speedo which is currently being undertaken by colleagues at Saxonica.

In essence I have found that doing repeated executions of a transformation which involves the creation of a stylesheet and an XdmValue object I was getting the out of memory exception after running through a large number of test cases. I have addressed the exception in a number of ways:

1. Implemented the methods releaseStylesheet and releaseXdmValue in the XsltProcessor and XdmValue classes, respectively.

2. Implemented the compile method to cache the compiled stylesheet for repeated execution

3. Fixed up the parseXmlFile and parseXMLString methods so that it can be used repeatably by the currently compiled stylesheet or in the one-shot transformation methods. As mentioned in point 1. the XdmValue object created can now be safely deleted.

There has been a quite a number of small fixes that will improve the overall performance of Saxon-C, which will be in the next release along with the fixes described above.

This bug has been resolved in later releases.

Thanks for reporting the problem you have found. We will investigate the problem and get back to you.

Hi!

Sorry for keeping you waiting.

A very simple test would be this one:

Running that code snippet in my local Docker container, I see that additional 9 child threads are running, but they stay alive until I manually kill them.

I am attaching a screen dump from "htop" - not sure if it makes it through…

Regards,

Frank

No progress I am afraid to say. Thank you for bringing this bug issue back up. I have tried following comment #11 and also tried added a release() method to the PHP API but the 13 threads are still showing up.

Currently investigating this further.

Hi,

I am pleased to say I have finally fixed this bug issue. The fix was to setup the JET VM in the PHP_MINIT_FUNCTION(saxon) function and then calling SaxonProcessor::release() in the PHP_MSHUTDOWN function. All other calls on the release method were removed. Patch available in the next major release.

Result in executed PHP script:

Process ID :5363
Number of threads: 1
--------------------
Number of threads: 1

As a workaround for users you can do the following (In the php7_saxon.cpp file):

1. Add the method:

void php_saxonc_initialize(void){
   if(SaxonProcessor::jvmCreatedCPP == 0){
	SaxonProcessor::jvmCreatedCPP=1;
    //SaxonProcessor::sxn_environ= new sxnc_environment;
	SaxonProcessor::sxn_environ= (sxnc_environment *)malloc(sizeof(sxnc_environment));

    /*
     * First of all, load required component.
     * By the time of JET initialization, all components should be loaded.
     */

    SaxonProcessor::sxn_environ->myDllHandle = loadDefaultDll ();

    /*
     * Initialize JET run-time.
     * The handle of loaded component is used to retrieve Invocation API.
     */
    initDefaultJavaRT (SaxonProcessor::sxn_environ); 
    }
}

2. In the PHP_MINIT_FUNCTION(saxon) function add a call to the new function given above:

    php_saxonc_initialize();

3. The PHP_MSHUTDOWN_FUNCTION now looks like the following:

PHP_MSHUTDOWN_FUNCTION(saxon) {
    SaxonProcessor::release();
    UNREGISTER_INI_ENTRIES();
    return SUCCESS;
}

Big fix applied in the Saxon/C 1.2.0 release.

I am reopening this bug issue because this fix presented in comment note 16 causes hanging issues when the PHP script is executed in the browser. Related to bug #4371

This fix has now been resolved in SaxonC 11