gistfile1.txt

Install Caliper http://code.google.com/p/caliper/
Clone https://github.com/chrisvest/stormpot
$ mvn package && ./benchmark stormpot.benchmark.PartitionSelect
Compare ModuloAtomicCount with ModuloIdentityHashNewObject
 - you may subtract ModuloConst from both if you want, or
   ModuloIdentityHashThread from ModuloIdentityHashNewObject,
   to remove a bit of the overhead.

On my MacPro:

              benchmark    ns linear runtime
            ModuloConst  1.19 =
         ModuloThreadId  1.99 =
      ModuloAtomicCount 11.94 ====
  ModuloScalableCounter 10.17 ===
         ThreadLocalRef  5.39 =

ModuloIdentityHashThread 4.01 =
ModuloIdentityHashNewObject 84.37 ==============================
ModuloHashNewObject 80.12 ============================
ModuloHashBoxed 6.13 ==
ModuloHashNotBoxed 2.73 =

where:
hashNewObject just calls the new Object.hashCode()
hashBoxed boxes the loop counter to an Integer and calls hashCode()
hashNotBoxed just adds the loop counter

I think the JIT is optimising most of the paths so well it overestimates the cost of the new Object – but that is just theory

There are probably special JIT heuristics that apply to Integer. Caliper currently have some shortcomings with regards to what parameters you can pass to the measuring JVMs - it would be interesting to see the new Object() results with Escape Analysis turned on. I reckon that would bring the ModuloHashNewObject results very close to that of ModuloHashBoxed.