FasterXML performance regression when dealing with list?

I'm evaluating fasterXML (v 2.11.0) performance under different configurations ("simple" objectMapper, using afterburner, smile, etc) and during my jmh performance tests I found some strange results.
It seems that the performance for de-serializing a list is very very poor.
Here is the method used for the test

protected void testMapper(List<Persona> persone, Blackhole bh,ObjectMapper jsonMapper) throws Exception {
    String personeAsStr=jsonMapper.writeValueAsString(persone);
    bh.consume(personeAsStr);
    List<Persona> personeDeser=jsonMapper.readValue(personeAsStr,List.class);
    bh.consume(personeDeser);
}

If instead of List<Persona> I use an object containing the persona as properties the performance is totally different.

Here is the code used for the other test

protected void testMapperPersone(PersoneForBenchmark personeForBenchmark, Blackhole bh,ObjectMapper jsonMapper) throws Exception {
    String personeAsStr=jsonMapper.writeValueAsString(personeForBenchmark);
    bh.consume(personeAsStr);
    PersoneForBenchmark personeDeser=jsonMapper.readValue(personeAsStr,PersoneForBenchmark.class);
    bh.consume(personeDeser);
}

Where PersonaForBenchmark is something like:

public class PersoneForBenchmark {
    private Persona persona0;
    private Persona persona1;
    private Persona persona2;
    private Persona persona3;
    private Persona persona4;
    private Persona persona5;
    private Persona persona6;
    private Persona persona7;
    private Persona persona8;
    private Persona persona9;
    //plus getters and setters
} 

The performance results are the following one:

FasterXMLPerformance.fasterXMLStandard 19,504 ops/s

FasterXMLPerformance.fasterXMLStandardPersone 10772,836 ops/s

I tried to use a TypeReference, an Object holding the list, but the results are essentially the same. Another aspect that is puzzling me is that the throughput of the test (for the list test case) decrease after each iteration. Here is an example of jmh log:

 Run progress: 18,75% complete, ETA 00:16:30
 Fork: 1 of 1
 Warmup Iteration   1: 218,673 ops/s
 Warmup Iteration   2: 83,445 ops/s
 Warmup Iteration   3: 57,964 ops/s
 Warmup Iteration   4: 46,002 ops/s
 Warmup Iteration   5: 39,482 ops/s
 Warmup Iteration   6: 34,743 ops/s
 Warmup Iteration   7: 31,322 ops/s
 Warmup Iteration   8: 28,361 ops/s
 Warmup Iteration   9: 26,241 ops/s
 Warmup Iteration  10: 24,520 ops/s
Iteration   1: 23,291 ops/s
Iteration   2: 22,062 ops/s
Iteration   3: 20,236 ops/s
Iteration   4: 19,886 ops/s
Iteration   5: 19,379 ops/s

The full test suite is available here.
Can anyone tell me if I'm doing something wrong or is it really a performance regression?

I can not see an immediate problem with test setup, and I think it is great that you are using jmh which is a solid good performance framework.

I agree that results you see are puzzling; and especially so degrading performance over test runs.

With that, I would suggest you file an issue for jackson-databind github repo, with some of information from above, and link to this question.
I will add some more suggestions on Gitter chat (https://gitter.im/FasterXML/jackson-databind)

But one immediately useful thing would be to know if specific older versions did not have this issue. There were changes in 2.11 about type resolution (it has been tweaker over time) which could have caused regression for some use case -- we do benchmark performance but mostly with just simpler Lists (List<String> etc).