Configuration options for generating bytecode
BytecodeCandidate.targetExpression(), the decision whether or not to generate bytecode depends on the setting of
This is wrong for a number of reasons:
(a) the code is executed in XQuery as well as XSLT
(b) the decision whether or not bytecode generation is enabled has already been made when injecting a ByteCodeCandidate into the expression tree; there is no need for a further check at this stage
(c) the option is not switched at configuration level anyway, but at the level of an XsltCompiler or XQueryCompiler.
The simplest solution is just to remove this check.
However, I think we may need further thought for the case where a stylesheet is loaded from an export file. At present in this situation I suspect we are not generating bytecode at all. That may be a separate issue.
Updated by Michael Kay over 3 years ago
- Status changed from New to In Progress
- Applies to branch 9.8, 9.9 added
- Fix Committed on Branch 9.8, 9.9 added
There seems to be quite a complex story here. It looks to me (subject to confirmation) as if:
In XSLT, if bytecode generation is enabled, then we generate ByteCodeCandidate expressions at appropriate points in the code, and these cause bytecode to be generated if and when the relevant section of code is executed often enough to trigger it.
In XQuery, we generate ByteCodeCandidates for the main query expression, but for function bodies, we generate bytecode unconditionally, and for global variables, we do not generate bytecode at all.
For code that is reloaded from SEF files, I don't think we currently generate bytecode.
The test within ByteCodeCandidate.targetExpression on
config.isGenerateByteCode(XSLT) is redundant for XSLT, and potentially damaging for XQuery because it means bytecode will not be generated for the main XQuery expression if the user has an EEQ license only. Removing this call seems simple and safe, though it's possibly not the end of the story. I will remove this call for both 9.8 and 9.9.
Please register to edit this issue