Tests: vmTestbase/nsk/monitoring/stress/lowmem/lowmem034/TestDescription.java
VM options: -XX:+CreateCoredumpOnCrash -XX:+IgnoreUnrecognizedVMOptions -XX:+UseSerialGC -Xmixed -XX:+TieredCompilation
Product tested: JDK 17.0.5-5-185 (ATR run)
OS/architecture: Linux-x64
Reproducible: Intermittent, failed 2 times on running 50 repetitions.
Is it a Regression: No, failing intermittently in previous builds too.
Is it a platform-specific issue: Not sure, currently seen only with linux-x64.

Error:

MemoryMonitor > Collection threshold is set, pool: sun.management.MemoryPoolImpl@20ff0906, usage: init = 12976128(12672K) used = 0(0K) committed = 34603008(33792K) max = 34603008(33792K), threshold: 32972799
# ERROR: MemoryMonitor > Unexpected exception while retrieving isCollectionUsageThresholdExceeded() for pool Eden Space
The following stacktrace is for failure analysis.
nsk.share.TestFailure: MemoryMonitor > Unexpected exception while retrieving isCollectionUsageThresholdExceeded() for pool Eden Space
at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:432)
at nsk.share.Log.complain(Log.java:403)
at nsk.share.Log$Logger.complain(Log.java:736)
at nsk.monitoring.share.Monitor.complain(Monitor.java:320)
at nsk.monitoring.share.MemoryMonitor$Polling.pollCollectionThresholds(MemoryMonitor.java:1496)
at nsk.monitoring.share.MemoryMonitor$Polling.run(MemoryMonitor.java:1280)
java.lang.IllegalArgumentException: committed = 276889600 should be < max = 276824064
at java.management/java.lang.management.MemoryUsage.<init>(MemoryUsage.java:166)
[...]

There is also a discrepancy between native and Java part of MemoryUsage specification between commited and max memory:

 - java.lang.management.MemoryUsage says
            * committed:
            * represents the amount of memory (in bytes) that is
            * guaranteed to be available for use by the Java virtual machine.
            * The amount of committed memory may change over time (increase
            * or decrease). The Java virtual machine may release memory to
            * the system and committed could be less than init.
            * committed will always be greater than or equal to used.
            * max:
            * represents the maximum amount of memory (in bytes)
            * that can be used for memory management. Its value may be undefined.
            * The maximum amount of memory may change over time if defined.
            * The amount of used and committed memory will always be less than or equal to max if max is defined.
            * A memory allocation may fail if it attempts to increase the used memory such that used > committed even
            * if used <= max would still be true (for example, when the system is low on virtual memory).
- vm/services/memoryUsage.hpp says
            // committed - represents the amount of memory (in bytes) that is
            // guaranteed to be available for use by the Java virtual machine.
            // The amount of committed memory may change over time (increase
            // or decrease). It is guaranteed to be greater than or equal
            // to initSize.
            // maxSize - represents the maximum amount of memory (in bytes)
            // that can be used for memory management. The maximum amount of
            // memory for memory management could be less than the amount of
            // committed memory. Its value may be undefined.

So in case of this test we call native method (sun.management.MemoryPoolImpl.getCollectionUsage0) to retrieve MemoryUsage object. Native side creates it (MemoryService::create_MemoryUsage_obj) based on native object with unexpected values for Java side.