RFR (XXS) 8080535: (ch) Expected size of Character.UnicodeBlock.map is not optimal

[Paul Sandoz]

On May 18, 2015, at 8:52 PM, Martin Buchholz <martinrb at google.com> wrote:

> On Fri, May 15, 2015 at 5:59 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
> wrote:
> 
>> 
>> 
>> On 16.05.2015 2:18, Martin Buchholz wrote:
>> 
>> I wouldn't bother defining the constant.
>> 
>> 
>> I only need it in the regression test, to check whether it was
>> sufficient.
>> 
> 
> The problem you're trying to solve is (a small amount of) startup overhead.
> Don't introduce __more__ startup overhead (another constant in the class
> file) just to make your change more testable.
> 

I agree, the use of the constant just for test purposes made me uncomfortable. Although the startup up cost for a constant would be far less than an additional resize of the map. Still i would prefer another way.

For now i would just bump up the initial capacity to 512, since that is what the table size will be and the number entries should be between 193 and 384 (256 * 0.75  + 1 and 512 * 0.75 respectively), state that in a comment. IMO the test for HashMap resizes should be a general test (perhaps it exists already?).

Paul.

> If you're serious about reducing overhead for static maps, you could:
> - write a java agent that verifies that all maps stored in static fields
> are never resized or oversized, and run all jtreg tests with that agent
> - use a true immutable static compact map implementation, perhaps optimized
> for String keys, in the spirit of
> jdk/src/share/classes/sun/util/PreHashedMap.java
> - initialize the static maps from a binary blob stored in a resource
> instead of from java code
> 
> but any of those is a lot of work.  I would just check in the fix to
> s/256/BETTER_SIZE/