On May 18, 2015, at 8:52 PM, Martin Buchholz <marti...@google.com> wrote:
> On Fri, May 15, 2015 at 5:59 PM, Ivan Gerasimov <ivan.gerasi...@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/
