Unusual behavior of java.util.Optional in benchmark mode

[John Auden]

Aleksey, Bernd,

Thanks a lot for your hints, I modified test to use "SingleShotTime"
mode and now able to predict memory allocation

Regards,
Alex Dubrouski

On Thu, Sep 12, 2019 at 12:01 PM Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
>
> The ratio between Optional and String instances should however be 1:1 (Optionals of null point all to the same empty Singleton). I wonder if this is a heapdump/Gc/stringtable thing, can you maybe try to add a run-unique string to the value strings?
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> ________________________________
> Von: jmh-dev <jmh-dev-bounces at openjdk.java.net> im Auftrag von Aleksey Shipilev <shade at redhat.com>
> Gesendet: Donnerstag, September 12, 2019 8:40 PM
> An: John Auden; jmh-dev at openjdk.java.net
> Betreff: Re: Unusual behavior of java.util.Optional in benchmark mode
>
> On 9/12/19 8:32 PM, John Auden wrote:
> > 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.
>
> You apparently think that "iteration" is one call to @Benchmark. It is not, there are multiple
> invocations of @Benchmark in AverageTime/Throughput modes, which would call @Benchmark continuously,
> until time allows.
>
> --
> Thanks,
> -Aleksey
>