RFR 8217518: Crypto benchmarks not warming up in time
claes.redestad at oracle.com
Tue Jan 22 15:35:23 UTC 2019
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)?
On 2019-01-22 16:24, Adam Petcher wrote:
> 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
More information about the jdk-dev