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
