JDK-8237045 : JVM uses excessive memory with -XX:+EnableJVMCI -XX:JVMCICounterSize=2147483648
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13,14,15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-01-13
  • Updated: 2020-06-11
  • Resolved: 2020-03-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 15
11.0.8-oracleFixed 13.0.4Fixed 15 b15Fixed
Description
There should be a reasonable range check for this flag, so it doesn't use excessive memory.

Currently,  -XX:JVMCICounterSize=2147483648 is actually tested by
runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java. However,  -XX:+EnableJVMCI is not specified, so the JVM fails to launch with 

Improperly specified VM option 'JVMCICounterSize': 'EnableJVMCI' must be enabled
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

However, if this test is executed with  -XX:+EnableJVMCI, it will allocate so much memory that my machine will be unresponsive for about 2 minuets.
Comments
Fix request (13u) I'd like to backport it to 13u as well. The patch applies cleanly, tier1 and the provided test work as expected.
11-06-2020
Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.8-oracle. Applies clean.
14-04-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/157a7e7033d9 User: kvn Date: 2020-03-17 19:42:59 +0000
18-03-2020
http://cr.openjdk.java.net/~kvn/8237045/webrev.00/
13-03-2020
Thank! These numbers looks reasonable. Note to myself counters allocation is long[] arrays in native memory.
06-03-2020
2^20 counters (an extremely large value which noone will use under normal circumstances) will consume 8mb, which means 8gb for the example of 1000 threads. Extreme option values lead to extreme resource consumption, that's true for many options that the JVM has (consider, e.g., -Xms128g).
06-03-2020
What size of each counter? How much memory you will need for all 2^20 counters? What is concerning is it is not only size for one array static JavaThread::_jvmci_old_thread_counters but also for each Java threads array JavaThread::_jvmci_counters http://hg.openjdk.java.net/jdk/jdk/file/fbbcf9125cef/src/hotspot/share/runtime/thread.cpp#l1611 So if you have 1000 threads you will have to multiply it to get total needed memory.
05-03-2020
10k is too low for very fine-grained counters, something like 2^20 seems reasonable.
05-03-2020
I would suggest reducing the range: experimental(intx, JVMCICounterSize, 0, \ "Reserved size for benchmark counters") \ - range(0, max_jint) \ + range(0, 10000) \ \ [~lstadler] is 10000 a reasonable limit?
04-03-2020
[~dnsimon] Do you have any suggestions?
04-03-2020
ILW = JVM allocates excessive amounts of memory, with large, non-default flag value, disable JVMCI = HLM = P3
14-01-2020