Project

Profile

Help

Bug #4046

closed

Bytecode is not generated for stylesheets that are exported and then reloaded.

Added by Michael Kay almost 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Byte code generation
Sprint/Milestone:
-
Start date:
2018-11-21
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.9
Fix Committed on Branch:
9.9
Fixed in Maintenance Release:
Platforms:

Description

No code is generated in the SEF file to represent a ByteCodeCandidate expression, and therefore in code reloaded from a SEF file, no bytecode is generated.

Actions #1

Updated by Michael Kay almost 4 years ago

  • Status changed from New to In Progress

I have changed the package loader (which reloads code from the SEF file) to inject byte code candidates into the reconstructed expression tree.

This results in some 16 test failures in XSLT3:

  analyze-string : 2
  error : 1
  function : 4
  si-fork : 3
  su-absorbing : 1
  su-shallow-descent : 5

which I will now examine.

Actions #2

Updated by Michael Kay almost 4 years ago

analyze-string-090b and analyze-string-092 are reporting an error XTDE1150: The regular expression must not be one that matches a zero-length string. This error no longer exists in 3.0, but the generated bytecode is still testing for it.

The interpreted code checks for the error too, but only if dialect="XP20" which is never true.

The reason it doesn't fail in the non-export case is that the regular expression is known and compiled at stylesheet compile time, so the generated bytecode does not need to compile it or check it. So there's a root cause of the problem here, namely that with reloaded code, the regex isn't being precompiled. (However, 9.9 introduced regex caching, so this doesn't matter as much as it once did.)

I have removed the error check from both the interpreted and compiled path and the test cases are now working both with and without export.

But this leaves the question why the regex is not being precompiled.

For system functions like matches(), the package loader has a completion action which calls SystemFunction.fixArguments() which enables the function to do any optimizations based on the fact that some arguments are fixed. However, Matches (and its superclass RegexFunction) do not implement this method. Instead they have a method tryToBindRegularExpression(), which is called during function call creation (SystemFunction.makeFunctionCall()) and therefore happens automatically during package loading.

To get the same effect with analyze-string we should invoke the "precompute regex" functionality of the AnalyzeString expression immediately after creating the expression. DONE.

Actions #3

Updated by Michael Kay almost 4 years ago

The four tests that are failing in the function test set are:

  function-5005
  function-5006
  function-5015
  function-5016

These are streaming failures. We shouldn't attempt bytecode generation (or it should be a no-op) for streamable stylesheet functions. DONE

Actions #4

Updated by Michael Kay almost 4 years ago

  • Status changed from In Progress to Resolved
  • Priority changed from Low to Normal
  • Fix Committed on Branch 9.9 added

This leaves one failure, which is already the subject of bug #4037.

Actions #5

Updated by O'Neil Delpratt over 3 years ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.9.1.1 added

Bug fix applied to the Saxon 9.9.1.1 maintenance release.

Actions #6

Updated by O'Neil Delpratt over 3 years ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF