Shenandoah performance problem

[Aleksey Shipilev]

On 10/17/19 1:01 AM, Attila Axt wrote:
> Do you consider this as a bug?

Yes! Thanks for reporting.

Much simpler reproducer:

package axt.benchmark;

import java.io.*;
import java.util.*;
import java.util.concurrent.TimeUnit;
import java.util.zip.GZIPInputStream;
import java.util.zip.GZIPOutputStream;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Threads(Threads.MAX)
@Fork(1)
@State(Scope.Thread)
public class TranscodeBenchmark {
    byte[] src;

    @Setup
    public void setUp() throws Exception {
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        try (GZIPOutputStream gos = new GZIPOutputStream(baos);
             ObjectOutputStream oos = new ObjectOutputStream(gos)) {
            oos.writeObject(new byte[65536]);
        }
        baos.close();
        src = baos.toByteArray();
    }

    @Benchmark
    public Object test() throws Exception {
        try (ByteArrayInputStream bais = new ByteArrayInputStream(src);
             GZIPInputStream gis = new GZIPInputStream(bais);
             ObjectInputStream ois = new ObjectInputStream(gis)) {
            return ois.readObject();
        }
    }
}

Plus, using the proper JMH runner allows to select thread counts without recompiling with -t.

This workload runs:
  Parallel GC, -t 1:     0.112 ± 0.006  ms/op
  Parallel GC, -t max:   0.146 ± 0.002  ms/op
  Shenandoah GC, -t 1:   0.120 ± 0.002  ms/op
  Shenandoah GC, -t max: 1.595 ± 0.050  ms/op <--- scalability bottleneck


And you are right, that's the contention on pinning/unpinning, I am looking what can be done about
that...

-- 
Thanks,
-Aleksey