Warning: Bytecode generation failed for [my:function]: null

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Warning: Bytecode generation failed for [my:function]: null

Matthieu RICAUD-DUSSARGET-2
Hi all,

We recently moved from saxon EE 9.5.1.5 to saxon EE 9.7.0.13 and we faced a few problems.

(The first was this : "XTDE1480: Cannot execute xsl:result-document while evaluating variable" => I will maybe send another topic for this,
we found a solution but I would have like to know why this worked on saxon 9.5 and why this restriction in 9.6+, because o bytecode generation ?)

We have these kind of warnings with saxon EE 9.7 (which we didn't have with saxon 9.5 EE) :
"Warning: Bytecode generation failed for els:makeIsoDate: null"

This is just a warning so I guess we should not worry too much, but if we can avoid it, it would be great and feel us more confident.
This is the code of the function els:makeIsoDate, do you think I should change anything to make it "Bytecode generation able" ? or desactivate bytecode generation ? :

<xd:doc>
  <xd:desc>
    <xd:p>Convert a string with format "JJ/MM/AAAA" (or "JJ-MM-AAAA" or "JJ/MM/AA") to a string representing an ISO date format "AAAA-MM-JJ"</xd:p>
    <xd:param name="s">String to convert as iso date string</xd:param>
    <xd:param name="sep">string representing the separator "/" (or something els) within the original string ($s)</xd:param>
  </xd:desc>
  <xd:return>Iso date of $s as a xs:string (if the convesion fails, it will return the original $s string)</xd:return>
</xd:doc>
<xsl:function name="els:makeIsoDate" as="xs:string">
  <xsl:param name="s" as="xs:string?"/>
  <xsl:param name="sep" as="xs:string"/>
  <xsl:variable name="sToken" select="tokenize($s, $sep)" as="xs:string*"/>
  <xsl:variable name="regJJMMAAAA" as="xs:string" select="concat('^\d\d', $sep, '\d\d', $sep, '\d\d\d\d$')"/>
  <xsl:variable name="regJJMMAA" as="xs:string" select="concat('^\d\d', $sep, '\d\d', $sep, '\d\d')"/>
  <xsl:choose>
    <!--If $s is empty, we can't do anything : return the empty string-->
    <xsl:when test="empty($s)">
      <xsl:value-of select="''"/>
    </xsl:when>
    <!--If $sep is empty, we can't do anything : return the original string $s-->
    <xsl:when test="$sep = ''">
      <xsl:value-of select="$s"/>
    </xsl:when>
    <!--The string $s format is correct "JJ/MM/AAAA" : convert it to "AAAA-MM-JJ" -->
    <xsl:when test="matches($s, $regJJMMAAAA)">
      <xsl:value-of select="concat($sToken[3], '-', $sToken[2], '-', $sToken[1])"/>
    </xsl:when>
    <!--The string $s format is correct except the year which is on 2 digit "JJ/MM/AA" : convert it to "AAAA-MM-JJ" (trying to guess the century)-->
    <!--ASSUME : if AA is later than current AA, we consider AA was in the last century-->
    <xsl:when test="matches($s, $regJJMMAA)">
      <xsl:variable name="currentAAAA" select="year-from-date(current-date())" as="xs:integer"/>
      <xsl:variable name="currentAA__" select="substring(string($currentAAAA), 1, 2) cast as xs:integer" as="xs:integer"/>
      <xsl:variable name="current__AA" select="substring(string($currentAAAA), 3, 2) cast as xs:integer" as="xs:integer"/>
      <xsl:variable name="AA" select="xs:integer($sToken[3])" as="xs:integer"/>
      <xsl:variable name="AAAA" select="if ($AA gt $current__AA) then (concat($currentAA__ -1, $AA))  else (concat($currentAA__, $AA))" as="xs:string"/>
      <xsl:value-of select="concat($AAAA, '-', $sToken[2], '-', $sToken[1])"/>
    </xsl:when>
    <!--Unknown format : return the original string $s-->
    <xsl:otherwise>
      <xsl:value-of select="$s"/>
    </xsl:otherwise>
  </xsl:choose>
</xsl:function>

By the way, I used -TP option to compare performances of the same transformation (except that we had to descativate result-document with 9.7) :
- With saxon 9.5 it takes 484 ms
- With saxon 9.7 it takes 707 ms
I was a bit surprised, any ideas / comments about this ?

Cordialement,

 
 
Matthieu Ricaud-Dussarget
Expert XML
SI EDITORIAL
[hidden email]
Tél : 01 40 92 21 98
80 Avenue de la Marne - 92120 Montrouge



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Warning: Bytecode generation failed for [my:function]: null

Michael Kay
>
> (The first was this : "XTDE1480: Cannot execute xsl:result-document while evaluating variable" => I will maybe send another topic for this,
> we found a solution but I would have like to know why this worked on saxon 9.5 and why this restriction in 9.6+, because o bytecode generation ?)

Probably because we fixed a bug. Would need to see the details.
>
> We have these kind of warnings with saxon EE 9.7 (which we didn't have with saxon 9.5 EE) :
> "Warning: Bytecode generation failed for els:makeIsoDate: null"

It's probably a mistake to be outtputting these warnings. Unfortunately it can mean either than bytecode generation failed by design (we found a construct for which bytecode generation is not implemented), or that it failed because of some internal problem. We started outputting the warnings because we felt that the internal problems were going unnoticed and should receive attention, but the consequence is unnecessary alarm for cases where we probably made a conscious decision that generating bytecode would give no benefit.

For this function, bytecode generation is working for me.

But yes, you don't need to worry about it because falling back to interpreted mode is normal.
>
>
>
> By the way, I used -TP option to compare performances of the same transformation (except that we had to descativate result-document with 9.7) :
> - With saxon 9.5 it takes 484 ms
> - With saxon 9.7 it takes 707 ms
> I was a bit surprised, any ideas / comments about this ?
>

-TP will increase execution times because timing/tracing code has been inserted into the expression tree. So these times are not directly comparable. For useful timings use the -t option on the command line, and if the execution time is under a second as here, run with -repeat:50 to eliminate warm-up time.

We've fixed a number of performance regressions during the life of 9.7, but there's always a danger that when we improve the performance of one particular workload that we are studying, other workloads slowly degrade because they aren't receiving the same level of attention.

Michael Kay
Saxonica


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Warning: Bytecode generation failed for [my:function]: null

Matthieu RICAUD-DUSSARGET-2
Hi Michael and thank you for your quick answer !

I'll sent another post with more details for the 1st problem.

About this one, I don't know why you don't have those warnings, maybe you are using another version than mine ?
Anyway, I won't look more, as you said, no need to worry :)
Just a question :

Is it possible to avoid those specifics warning inn saxon configuration file for example ?

We would also like to prevent the common warning :
"Stylesheet module ... is included or imported more than once. This is permitted, but may lead to errors or unexpected behavior"
Our XSLT atchitectur is really modular (with maven dependencies to other xslt using a specific "classpath protocol") and we can't avoid importing a few times the same xslt lib. I know these warning message has been added because of one case with thousands of same import, but in our case, we think this is normal.
But is scares a few people to see those kins of warning, and it make the processing really verbose, preventing seeing maybe other warnings...

About perf :
With -t option, I get something quite similar :
- With saxon 9.5 : Execution time: 673ms
- With saxon 9.7 : Execution time: 732 ms

This include java warm up time..
But when I add -repeat option (=more than 1) the transformation is stopped (with both version of saxon) with the following message (it's ok without -repeat option) :

Saxon-EE 9.5.1.5J from Saxonica
Java version 1.8.0_05
Using license serial number V001135
Warning: Stylesheet module cp:/xslLib/els-common.xsl is included or imported more than once. This is permitted, but may lead to errors or unexpected behavior
Warning: Stylesheet module cp:/xslLib/functx.xsl is included or imported more than once. This is permitted, but may lead to errors or unexpected behavior
Warning: Stylesheet module cp:/xslLib/functx.xsl is included or imported more than once. This is permitted, but may lead to errors or unexpected behavior
Warning: Stylesheet module xslLib:/xslLib/els-common.xsl is included or imported more than once. This is permitted, but may lead to errors or unexpected behavior
Warning: Stylesheet module cp:/xslLib/functx.xsl is included or imported more than once. This is permitted, but may lead to errors or unexpected behavior
Loading net.sf.saxon.option.local.Numberer_fr
Cannot run els:reccursivReplace in compile mode - using interpreter
Cannot run functx:replace-multi in compile mode - using interpreter
Generating byte code...
Stylesheet compilation time: 2002 milliseconds
Error
  I/O error reported by XML parser processing
  cp:/xf-ecmRes/efl/infoCommentaire.htmlFullPreview.xsl: Stream closed
Failed to compile stylesheet. 1 error detected.

Strange ?

Cheers,
Matthieu

-----Message d'origine-----
De : Michael Kay [mailto:[hidden email]]
Envoyé : vendredi 2 décembre 2016 15:44
À : Mailing list for the SAXON XSLT and XQuery processor
Objet : Re: [saxon] Warning: Bytecode generation failed for [my:function]: null

>
> (The first was this : "XTDE1480: Cannot execute xsl:result-document
> while evaluating variable" => I will maybe send another topic for
> this, we found a solution but I would have like to know why this
> worked on saxon 9.5 and why this restriction in 9.6+, because o
> bytecode generation ?)

Probably because we fixed a bug. Would need to see the details.
>
> We have these kind of warnings with saxon EE 9.7 (which we didn't have with saxon 9.5 EE) :
> "Warning: Bytecode generation failed for els:makeIsoDate: null"

It's probably a mistake to be outtputting these warnings. Unfortunately it can mean either than bytecode generation failed by design (we found a construct for which bytecode generation is not implemented), or that it failed because of some internal problem. We started outputting the warnings because we felt that the internal problems were going unnoticed and should receive attention, but the consequence is unnecessary alarm for cases where we probably made a conscious decision that generating bytecode would give no benefit.

For this function, bytecode generation is working for me.

But yes, you don't need to worry about it because falling back to interpreted mode is normal.
>
>
>
> By the way, I used -TP option to compare performances of the same transformation (except that we had to descativate result-document with 9.7) :
> - With saxon 9.5 it takes 484 ms
> - With saxon 9.7 it takes 707 ms
> I was a bit surprised, any ideas / comments about this ?
>

-TP will increase execution times because timing/tracing code has been inserted into the expression tree. So these times are not directly comparable. For useful timings use the -t option on the command line, and if the execution time is under a second as here, run with -repeat:50 to eliminate warm-up time.

We've fixed a number of performance regressions during the life of 9.7, but there's always a danger that when we improve the performance of one particular workload that we are studying, other workloads slowly degrade because they aren't receiving the same level of attention.

Michael Kay
Saxonica


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/ [hidden email] https://lists.sourceforge.net/lists/listinfo/saxon-help 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Loading...