Re: [jdk19] RFR: 8289486: Improve XSLT XPath operators count efficiency [v2]
> To improve efficiency, this patch moves the limit check to within the Lexer > and reports any overlimit situation as soon as it happens. > > Note the change in XPathParser: diff (and also webrevs) showed the whole > error-report block was changed, the actual change was only placing the block > to within the isOverLimit statement. > > Test: java.xml tests passed. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: add comments - Changes: - all: https://git.openjdk.org/jdk19/pull/101/files - new: https://git.openjdk.org/jdk19/pull/101/files/330f86ce..ef9cf7d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=101&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=101&range=00-01 Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/101.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/101/head:pull/101 PR: https://git.openjdk.org/jdk19/pull/101
Re: [jdk19] RFR: 8289486: Improve XSLT XPath operators count efficiency [v2]
On Thu, 7 Jul 2022 17:32:45 GMT, Joe Wang wrote: >> To improve efficiency, this patch moves the limit check to within the Lexer >> and reports any overlimit situation as soon as it happens. >> >> Note the change in XPathParser: diff (and also webrevs) showed the whole >> error-report block was changed, the actual change was only placing the block >> to within the isOverLimit statement. >> >> Test: java.xml tests passed. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revision: > > add comments Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.org/jdk19/pull/101
Re: [jdk19] RFR: 8289486: Improve XSLT XPath operators count efficiency
On Fri, 1 Jul 2022 17:04:10 GMT, Joe Wang wrote: > To improve efficiency, this patch moves the limit check to within the Lexer > and reports any overlimit situation as soon as it happens. > > Note the change in XPathParser: diff (and also webrevs) showed the whole > error-report block was changed, the actual change was only placing the block > to within the isOverLimit statement. > > Test: java.xml tests passed. Thanks for the explanation. Looks good to me. - Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk19/pull/101
Re: [jdk19] RFR: 8289486: Improve XSLT XPath operators count efficiency
On Fri, 1 Jul 2022 17:04:10 GMT, Joe Wang wrote: > To improve efficiency, this patch moves the limit check to within the Lexer > and reports any overlimit situation as soon as it happens. > > Note the change in XPathParser: diff (and also webrevs) showed the whole > error-report block was changed, the actual change was only placing the block > to within the isOverLimit statement. > > Test: java.xml tests passed. Hi Naoto, Thanks for reviewing. For counting, it's mainly the way the totalOpCount was accumulated (e.g. previously it was totalOpCount += opCount and now totalOpCount++). But since the limit on total ops is usually significantly larger than that of the count for one expression, this change won't have effect on how it was reported, that is, it won't be report before individual limit is reached. In that regard, the reporting sequence hasn't changed (that is, group -> individual count -> total). The other factor is that this feature is fairly new, the change therefore will unlikely affect any real-world applications. The test cases, reporting group/individual/total errors in the order, continued passing, that's a good indicator as well. - PR: https://git.openjdk.org/jdk19/pull/101
Re: [jdk19] RFR: 8289486: Improve XSLT XPath operators count efficiency
On Fri, 1 Jul 2022 17:04:10 GMT, Joe Wang wrote: > To improve efficiency, this patch moves the limit check to within the Lexer > and reports any overlimit situation as soon as it happens. > > Note the change in XPathParser: diff (and also webrevs) showed the whole > error-report block was changed, the actual change was only placing the block > to within the isOverLimit statement. > > Test: java.xml tests passed. Hi Joe, In the bug report, it reads: It would be more efficient for the XSLT XPath impl to do the same as the XPath impl does and report any error earlier So now the code works as once the first error was found, it immediately reports it. Would that result in a behavioral change, if there are multiple overflows co-exist? Would there be a possibility where a different error be thrown compared to the prior implementation? - PR: https://git.openjdk.org/jdk19/pull/101
[jdk19] RFR: 8289486: Improve XSLT XPath operators count efficiency
To improve efficiency, this patch moves the limit check to within the Lexer and reports any overlimit situation as soon as it happens. Test: java.xml tests passed. - Commit messages: - 8289486: Improve XSLT XPath operators count effiency Changes: https://git.openjdk.org/jdk19/pull/101/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=101&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289486 Stats: 49 lines in 2 files changed: 21 ins; 4 del; 24 mod Patch: https://git.openjdk.org/jdk19/pull/101.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/101/head:pull/101 PR: https://git.openjdk.org/jdk19/pull/101