JDK-8009928 : PSR:PERF Increase default string table size
  • Type: Bug
  • Component: performance
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-03-12
  • Updated: 2014-11-18
  • Resolved: 2013-10-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
The default string table size (particularly for FA) is too small and should be increased.

Increasing this size does affect the size of the string table bucket array, but the increase is minimal. For apps which set a size of 60013, the increase in the array size is 460K.
Check print flags final in 8-b111 (sorry for reopening, clicked the wrong button)

This is a simple, straight-forward change, with the only negative impact being a slight footprint increase. This is critical for Java SE 64-bit environments, and should be set as default for that build.

Most FMW, and all ADF-based Fusion Apps require an string table of 60013 or greater.

Right, as Dave K says we are talking about Fusion Apps (FA), which I unfortuantely did not make clear. For 64-bit server/tiered only, the footprint increase for non-FA apps would be minimal.

The current StringTable size is too small for just about any Fusion App. The size only needs to be set for server and tiered, and it isn't necessary for client. The suggested size is 60013 which will eliminate the performance impact when running Fusion Apps with +70K interned strings.

"too small" for what? Please provide more details on what apps find this too small and what you suggest as a new size. This may be a value that we need to conditionally set depending on the build (SE vs Embedded) or maybe even the platform. But there is insufficient information to act on this report as it stands.