Re: [jdk19] RFR: 8289486: Improve XSLT XPath operators count efficiency [v2]

2022-07-08 Thread Joe Wang
> 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]

2022-07-07 Thread Lance Andersen
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

2022-07-05 Thread Naoto Sato
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

2022-07-01 Thread Joe Wang
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

2022-07-01 Thread Naoto Sato
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

2022-07-01 Thread Joe Wang
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