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/
>