Unusual behavior of java.util.Optional in benchmark mode

[John Auden]

Good morning,

I was doing small research to find out performance of different
syntactical constructs and noticed very strange behavior of Optional
class. I am trying to find out whether issue resides in a way JMH
generates tests or it is more generic JVM bug.
Environment:
Debian 8 Jessie
AdoptOpenJDK 12.0.2, OpenJDK 64-Bit Server VM, 12.0.2+10
hsdis compiled from 12.0.2 tag with binutils 2.32
perf version 3.16.56
JMH v1.21

Entire test suite is here https://github.com/alex-dubrouski/java-test
This specific test is
https://github.com/alex-dubrouski/java-test/blob/master/src/main/java/org/ad/OptionalBenchmark.java
Test uses BlackHole to consume non-null objects from a huge ArrayList
in a loop. The idea was to compare If vs optional vs stream.filter
under heavy load. EpsilonGC used to avoid GC overhead.
If performs the best, stream is ok, but Optional benchmark dies during
warmup with OOM.
Heap analysis shows 133 millions of Optionals holding 50k strings
(VisualVM screenshots are here
https://github.com/alex-dubrouski/java-test/tree/master/images) after
just 2.5 iterations. Theoretically there should be 125K Optionals, not
133 millions.

I tried to do assembly code analysis, and I see where Optional is
being created (https://github.com/alex-dubrouski/java-test/blob/master/docs/conditionals/Optional.txt),
but still can't explain why there are 133 millions of them.

Would be very thankful if you can take a look and help me explain this.

Regards,
Alex Dubrouski