JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable reset

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

JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable reset

Aleks Efimov
Hi,

Please, help to review the fix [1] for a performance regression in
SPECjvm2008-XML benchmark. The cause of this regression was the
unconditional reset of SAX parsers symbol table during each reset()
operation introduced by JDK-8173390.
Proposed fix introduces new system property (CCC request is still
pending approval) that provides ability to control the symbol table
reset functionality. By default the reset table functionality is
disabled, similar to pre JDK-8173390 behavior. JAXWS parsers pool
implementation was updated to utilize new property to reset symbol table
only in JAXWS use-cases that helped to restore the performance levels to
pre JDK-8173390 level.

Modified regression test and XML related JCK tests passes on build with
proposed changes.

With Best Regards,
Aleksei

[1] http://cr.openjdk.java.net/~aefimov/8176168/00/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable reset

Lance Andersen
Hi Aleksei,

I think the change makes sense and pending CCC approval should be good to go :-)

Best
Lance

> On Apr 16, 2017, at 6:02 PM, Aleks Efimov <[hidden email]> wrote:
>
> Hi,
>
> Please, help to review the fix [1] for a performance regression in SPECjvm2008-XML benchmark. The cause of this regression was the unconditional reset of SAX parsers symbol table during each reset() operation introduced by JDK-8173390.
> Proposed fix introduces new system property (CCC request is still pending approval) that provides ability to control the symbol table reset functionality. By default the reset table functionality is disabled, similar to pre JDK-8173390 behavior. JAXWS parsers pool implementation was updated to utilize new property to reset symbol table only in JAXWS use-cases that helped to restore the performance levels to pre JDK-8173390 level.
>
> Modified regression test and XML related JCK tests passes on build with proposed changes.
>
> With Best Regards,
> Aleksei
>
> [1] http://cr.openjdk.java.net/~aefimov/8176168/00/

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
[hidden email] <mailto:[hidden email]>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable reset

huizhe wang
In reply to this post by Aleks Efimov
Hi Aleksej,

The changes look good. Some changes to the notes in the test may make it
a bit clearer on what scenarios are tested: move the current notes for
the method testResetEnabled to parseAndCheckReset, and then add scenario
description to the three test* methods, for example, testNoFeatureSet
verifies two scenarios: resetSymbolTable is and is not requested through
the System property, while testResetEnabled tests that the feature is
set  and testResetDisabled unset by using SAXParserFactory's setFeature
method regardless of whether the System property is set.

Best regards,
Joe

On 4/16/2017 3:02 PM, Aleks Efimov wrote:

> Hi,
>
> Please, help to review the fix [1] for a performance regression in
> SPECjvm2008-XML benchmark. The cause of this regression was the
> unconditional reset of SAX parsers symbol table during each reset()
> operation introduced by JDK-8173390.
> Proposed fix introduces new system property (CCC request is still
> pending approval) that provides ability to control the symbol table
> reset functionality. By default the reset table functionality is
> disabled, similar to pre JDK-8173390 behavior. JAXWS parsers pool
> implementation was updated to utilize new property to reset symbol
> table only in JAXWS use-cases that helped to restore the performance
> levels to pre JDK-8173390 level.
>
> Modified regression test and XML related JCK tests passes on build
> with proposed changes.
>
> With Best Regards,
> Aleksei
>
> [1] http://cr.openjdk.java.net/~aefimov/8176168/00/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable reset

Aleks Efimov
Hi Joe, Lance,

Thank you both for the reviews! I've updated the test methods with
comments per Joe suggestions [1]. Also the CCC request was approved
recently. If there will be no further comments I'll push the changes.

Best Regards,
Aleksei

[1] http://cr.openjdk.java.net/~aefimov/8176168/01/

On 19/04/17 21:41, huizhe wang wrote:

> Hi Aleksej,
>
> The changes look good. Some changes to the notes in the test may make
> it a bit clearer on what scenarios are tested: move the current notes
> for the method testResetEnabled to parseAndCheckReset, and then add
> scenario description to the three test* methods, for example,
> testNoFeatureSet verifies two scenarios: resetSymbolTable is and is
> not requested through the System property, while testResetEnabled
> tests that the feature is set  and testResetDisabled unset by using
> SAXParserFactory's setFeature method regardless of whether the System
> property is set.
>
> Best regards,
> Joe
>
> On 4/16/2017 3:02 PM, Aleks Efimov wrote:
>> Hi,
>>
>> Please, help to review the fix [1] for a performance regression in
>> SPECjvm2008-XML benchmark. The cause of this regression was the
>> unconditional reset of SAX parsers symbol table during each reset()
>> operation introduced by JDK-8173390.
>> Proposed fix introduces new system property (CCC request is still
>> pending approval) that provides ability to control the symbol table
>> reset functionality. By default the reset table functionality is
>> disabled, similar to pre JDK-8173390 behavior. JAXWS parsers pool
>> implementation was updated to utilize new property to reset symbol
>> table only in JAXWS use-cases that helped to restore the performance
>> levels to pre JDK-8173390 level.
>>
>> Modified regression test and XML related JCK tests passes on build
>> with proposed changes.
>>
>> With Best Regards,
>> Aleksei
>>
>> [1] http://cr.openjdk.java.net/~aefimov/8176168/00/
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable reset

huizhe wang
Looks fine.

-Joe

On 4/20/2017 5:17 PM, Aleks Efimov wrote:

> Hi Joe, Lance,
>
> Thank you both for the reviews! I've updated the test methods with
> comments per Joe suggestions [1]. Also the CCC request was approved
> recently. If there will be no further comments I'll push the changes.
>
> Best Regards,
> Aleksei
>
> [1] http://cr.openjdk.java.net/~aefimov/8176168/01/
>
> On 19/04/17 21:41, huizhe wang wrote:
>> Hi Aleksej,
>>
>> The changes look good. Some changes to the notes in the test may make
>> it a bit clearer on what scenarios are tested: move the current notes
>> for the method testResetEnabled to parseAndCheckReset, and then add
>> scenario description to the three test* methods, for example,
>> testNoFeatureSet verifies two scenarios: resetSymbolTable is and is
>> not requested through the System property, while testResetEnabled
>> tests that the feature is set  and testResetDisabled unset by using
>> SAXParserFactory's setFeature method regardless of whether the System
>> property is set.
>>
>> Best regards,
>> Joe
>>
>> On 4/16/2017 3:02 PM, Aleks Efimov wrote:
>>> Hi,
>>>
>>> Please, help to review the fix [1] for a performance regression in
>>> SPECjvm2008-XML benchmark. The cause of this regression was the
>>> unconditional reset of SAX parsers symbol table during each reset()
>>> operation introduced by JDK-8173390.
>>> Proposed fix introduces new system property (CCC request is still
>>> pending approval) that provides ability to control the symbol table
>>> reset functionality. By default the reset table functionality is
>>> disabled, similar to pre JDK-8173390 behavior. JAXWS parsers pool
>>> implementation was updated to utilize new property to reset symbol
>>> table only in JAXWS use-cases that helped to restore the performance
>>> levels to pre JDK-8173390 level.
>>>
>>> Modified regression test and XML related JCK tests passes on build
>>> with proposed changes.
>>>
>>> With Best Regards,
>>> Aleksei
>>>
>>> [1] http://cr.openjdk.java.net/~aefimov/8176168/00/
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable reset

Lance Andersen
In reply to this post by Aleks Efimov
Hi Aleksej

looks good

Best
Lance

> On Apr 20, 2017, at 8:17 PM, Aleks Efimov <[hidden email]> wrote:
>
> Hi Joe, Lance,
>
> Thank you both for the reviews! I've updated the test methods with comments per Joe suggestions [1]. Also the CCC request was approved recently. If there will be no further comments I'll push the changes.
>
> Best Regards,
> Aleksei
>
> [1] http://cr.openjdk.java.net/~aefimov/8176168/01/
>
> On 19/04/17 21:41, huizhe wang wrote:
>> Hi Aleksej,
>>
>> The changes look good. Some changes to the notes in the test may make it a bit clearer on what scenarios are tested: move the current notes for the method testResetEnabled to parseAndCheckReset, and then add scenario description to the three test* methods, for example, testNoFeatureSet verifies two scenarios: resetSymbolTable is and is not requested through the System property, while testResetEnabled tests that the feature is set  and testResetDisabled unset by using SAXParserFactory's setFeature method regardless of whether the System property is set.
>>
>> Best regards,
>> Joe
>>
>> On 4/16/2017 3:02 PM, Aleks Efimov wrote:
>>> Hi,
>>>
>>> Please, help to review the fix [1] for a performance regression in SPECjvm2008-XML benchmark. The cause of this regression was the unconditional reset of SAX parsers symbol table during each reset() operation introduced by JDK-8173390.
>>> Proposed fix introduces new system property (CCC request is still pending approval) that provides ability to control the symbol table reset functionality. By default the reset table functionality is disabled, similar to pre JDK-8173390 behavior. JAXWS parsers pool implementation was updated to utilize new property to reset symbol table only in JAXWS use-cases that helped to restore the performance levels to pre JDK-8173390 level.
>>>
>>> Modified regression test and XML related JCK tests passes on build with proposed changes.
>>>
>>> With Best Regards,
>>> Aleksei
>>>
>>> [1] http://cr.openjdk.java.net/~aefimov/8176168/00/
>>
>

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
[hidden email] <mailto:[hidden email]>



Loading...