RFR (XXS) 8080535: (ch) Expected size of Character.UnicodeBlock.map is not optimal
paul.sandoz at oracle.com
Tue May 19 09:08:00 UTC 2015
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>
>> 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
> 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?).
> 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
> - 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
More information about the core-libs-dev