RFR 8217518: Crypto benchmarks not warming up in time

[Claes Redestad]

Hi,

looks OK as a point fix for now, although we should consider if there
might be more robust ways that avoids hard-coding in flags. E.g, could
+AlwaysPreTouch have unfortunate side-effects on machines with extreme
amounts of RAM if you don't also limit maximum heap size (-Xmx)?

/Claes

On 2019-01-22 16:24, Adam Petcher wrote:
> Claes,
> 
> Please review this very small change that adds the "+AlwaysPreTouch" 
> option to the crypto benchmarks to allow them to warm up in time. This 
> fix is in response to Eric's discovery (when reviewing the new 
> benchmarks for KeyAgreement and Cipher) that the crypto benchmarks were 
> not warming up very well. Sergey discovered that the cause is memory 
> allocation overhead with large heaps and G1. Adding +AlwaysPreTouch does 
> more of this memory allocation work up front so it doesn't interfere 
> with the benchmark.
> 
> Webrev: http://cr.openjdk.java.net/~apetcher/8217518/webrev.00/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8217518
>