Hi Peter, Opportunistically if your LinearProbeHashtable works out then i am wondering if we could replace the use of CHM within MethodType.ConcurrentWeakInternSet, which only uses get/putIfAbsent/remove.
Thereby CHM can use VarHandles without inducing a circular dependency. Paul. > On 26 May 2016, at 10:59, Peter Levart <peter.lev...@gmail.com> wrote: > > Hi Michael, > > On 05/23/2016 03:56 PM, Michael Haupt wrote: >> I've ran the unpatched version and Peter's two patches once more. The >> results are attached (results.txt). They confirm Aleksey's observation. >> >> Regarding the 03 patch (plevart3 column in the results), perfasm output (see >> http://cr.openjdk.java.net/~mhaupt/8031043/perfasm.zip) suggests the cost is >> mainly accrued in ConcurrentHashMap. The same is the case for the 02 patch >> (plevart2 column). >> >> As things stand, I think we can even focus on Peter's 02 patch, as this is >> the faster of his two proposals (plevart2 column in the results), reduces >> the footprint, and reduces the implementation complexity. Can anything be >> done to improve on its performance? (It has slight performance slowdowns for >> the single-value case as well.) > > I can't think of anything else short of improving performance of CHM itself. > > Or replacing CHM with a "better" implementation: > > > http://cr.openjdk.java.net/~plevart/misc/ClassValue.Alternative2/webrev.04/ > > This webrev is similar to webrev.02. It's only difference is in ClassValueMap > which extends LinearProbeHashtable instead of ConcurrentHashMap. > LinearProbeHashtable is a simple implementation of a linear-probe hash table. > It's not a full Map implementation. It only implements methods needed in > ClassValue. With this implementation I get a slight boost compared to JDK 9 > ClassValue implementation for all sizes and counts: > > Benchmark (classCount) (classValueCount) (impl) > Mode Cnt Score Error Units > ClassValueBench.randomAccess 128 1 jdk9 > avgt 10 9.079 ± 0.092 ns/op > ClassValueBench.randomAccess 128 4 jdk9 > avgt 10 10.615 ± 0.102 ns/op > ClassValueBench.randomAccess 128 16 jdk9 > avgt 10 11.665 ± 0.012 ns/op > ClassValueBench.randomAccess 128 256 jdk9 > avgt 10 19.151 ± 0.219 ns/op > ClassValueBench.randomAccess 1024 1 jdk9 > avgt 10 14.642 ± 0.425 ns/op > ClassValueBench.randomAccess 1024 4 jdk9 > avgt 10 22.577 ± 0.093 ns/op > ClassValueBench.randomAccess 1024 16 jdk9 > avgt 10 19.864 ± 0.736 ns/op > ClassValueBench.randomAccess 1024 256 jdk9 > avgt 10 60.470 ± 0.285 ns/op > ClassValueBench.sequentialAccess 128 1 jdk9 > avgt 10 9.741 ± 0.033 ns/op > ClassValueBench.sequentialAccess 128 4 jdk9 > avgt 10 8.252 ± 0.029 ns/op > ClassValueBench.sequentialAccess 128 16 jdk9 > avgt 10 7.888 ± 1.249 ns/op > ClassValueBench.sequentialAccess 128 256 jdk9 > avgt 10 16.493 ± 0.415 ns/op > ClassValueBench.sequentialAccess 1024 1 jdk9 > avgt 10 13.376 ± 0.452 ns/op > ClassValueBench.sequentialAccess 1024 4 jdk9 > avgt 10 10.023 ± 0.020 ns/op > ClassValueBench.sequentialAccess 1024 16 jdk9 > avgt 10 8.029 ± 0.178 ns/op > ClassValueBench.sequentialAccess 1024 256 jdk9 > avgt 10 33.472 ± 0.058 ns/op > > Benchmark (classCount) (classValueCount) (impl) > Mode Cnt Score Error Units > ClassValueBench.randomAccess 128 1 pl04 > avgt 10 8.955 ± 0.055 ns/op > ClassValueBench.randomAccess 128 4 pl04 > avgt 10 9.999 ± 0.017 ns/op > ClassValueBench.randomAccess 128 16 pl04 > avgt 10 11.615 ± 1.928 ns/op > ClassValueBench.randomAccess 128 256 pl04 > avgt 10 17.063 ± 0.460 ns/op > ClassValueBench.randomAccess 1024 1 pl04 > avgt 10 12.553 ± 0.086 ns/op > ClassValueBench.randomAccess 1024 4 pl04 > avgt 10 16.766 ± 0.221 ns/op > ClassValueBench.randomAccess 1024 16 pl04 > avgt 10 18.496 ± 0.051 ns/op > ClassValueBench.randomAccess 1024 256 pl04 > avgt 10 41.390 ± 0.321 ns/op > ClassValueBench.sequentialAccess 128 1 pl04 > avgt 10 7.854 ± 0.381 ns/op > ClassValueBench.sequentialAccess 128 4 pl04 > avgt 10 7.498 ± 0.055 ns/op > ClassValueBench.sequentialAccess 128 16 pl04 > avgt 10 9.218 ± 1.000 ns/op > ClassValueBench.sequentialAccess 128 256 pl04 > avgt 10 13.593 ± 0.275 ns/op > ClassValueBench.sequentialAccess 1024 1 pl04 > avgt 10 8.774 ± 0.037 ns/op > ClassValueBench.sequentialAccess 1024 4 pl04 > avgt 10 8.562 ± 0.014 ns/op > ClassValueBench.sequentialAccess 1024 16 pl04 > avgt 10 7.596 ± 0.027 ns/op > ClassValueBench.sequentialAccess 1024 256 pl04 > avgt 10 24.605 ± 0.143 ns/op > > > The footprint is even better than with CHM as LPHT does not maintain internal > Map.Entry(s). > > How does this implementation compare on your hardware, Michael? > > Regards, Peter > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
