RFR (S) 8227123: Assertion failure when setting SymbolTableSize larger than 2^17 (131,072)

[Jiangli Zhou]

Hi Coleen,

On Tue, Jul 23, 2019 at 10:23 AM <coleen.phillimore at oracle.com> wrote:
>
>
>
> On 7/23/19 11:45 AM, Jiangli Zhou wrote:
> > On Tue, Jul 23, 2019 at 8:35 AM <coleen.phillimore at oracle.com> wrote:
> >>
> >>
> >> On 7/23/19 11:25 AM, Jiangli Zhou wrote:
> >>> Hi Coleen,
> >>>
> >>> On Mon, Jul 22, 2019 at 12:51 PM <coleen.phillimore at oracle.com> wrote:
> >>>> Thanks Jiangli, and for the suggestion to increase the max size.  I was
> >>>> waffling about removing the experimental option completely.
> >>> Would it be worth considering making SymbolTableSize a product flag?
> >>> There was a noticeable performance issue for a large application with
> >>> older JDK versions. It was found to be related to slow
> >>> SymbolTable::lookup due to too many collisions. Setting a large
> >>> initial symbol table size worked around the performance issue and the
> >>> improvement was significant. With newer JDK (> 12), user may still
> >>> prefer setting a large initial size to avoid any potential overhead
> >>> (avoid resizing) for large applications.
> >> I think the cost of resizing is low enough that it's not worth making it
> >> a product flag.  I know it doesn't match StringTableSize in this way.
> >> Ideally, customers should not have knowledge that these things are
> >> hashtables and should not have controls for internal implementation
> >> decisions.
> >>
> >> With resizing, both of these tables should perform acceptably out of the
> >> box.   Do we have any recent cases of customers needing to set this
> >> value to a large size, that may have prompted your bug report?
> > That was indeed the case, though it was with older JDK.
>
> Okay, that's good that it wasn't for the latest JDK.
> https://bugs.openjdk.java.net/browse/JDK-8019375 This bug has the
> history of why we made SymbolTableSize experimental, which still holds
> today, so I want to leave it as experimental.  I'm thinking in the
> future we could make StringTableSize experimental to match, and someday
> remove both, but not just now.

Thanks for the pointer. It might be beneficial to also measure the
potential resizing overhead in the future.

Best regards,
Jiangli

>
> Thanks,
> Coleen
>
> >
> > Best regards,
> > Jiangli
> >> Coleen
> >>
> >>> Best regards,
> >>> Jiangli
> >>>
> >>>> Coleen
> >>>>
> >>>> On 7/22/19 3:40 PM, Jiangli Zhou wrote:
> >>>>> Looks good.
> >>>>>
> >>>>> Best regards,
> >>>>> Jiangli
> >>>>>
> >>>>> On Mon, Jul 22, 2019 at 11:46 AM <coleen.phillimore at oracle.com> wrote:
> >>>>>> Summary: Increase max size for SymbolTable and fix experimental option
> >>>>>> range.  Make experimental options trueInDebug so they're tested by the
> >>>>>> command line option testing
> >>>>>>
> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8227123.01/webrev
> >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8227123
> >>>>>>
> >>>>>> Tested locally with default and -XX:+UseZGC since ZGC has a lot of
> >>>>>> experimental options.  I didn't test with shenanodoah.
> >>>>>>
> >>>>>> I will test with hs-tier1-3 before checking in.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Coleen
>