[9] RFR(S): 8166046: [TESTBUG] compiler/stringopts/TestStringObjectInitialization.java fails with OOME

Tobias Hartmann tobias.hartmann at oracle.com
Tue Sep 20 08:27:35 UTC 2016

Hi Vladimir,

On 19.09.2016 19:32, Vladimir Kozlov wrote:
> Should we scale down compilation threshold too? The test verifies C2 optimization we need to make sure that we still catch original JDK-8159244 problem.

I verified that the test still (rarely) triggers the problem I fixed with JDK-8159244 but while testing I found a better way to avoid the OOMEs:

This significantly reduces the runtime of the test from 1m30s to 12s on my machine and triggers JDK-8159244 in 100% of the runs. I verified that the patch still fixes the OOME's on the 32-bit Windows machines.


> Thanks,
> Vladimir
> On 9/19/16 5:15 AM, Tobias Hartmann wrote:
>> Hi,
>> please review the following patch:
>> https://bugs.openjdk.java.net/browse/JDK-8166046
>> http://cr.openjdk.java.net/~thartmann/8166046/webrev.00/
>> The test creates 101 threads that each execute a loop with 10.000 iterations that append to a String another String of size 17. This results in a String of size 101 * 10.000 * 17 = 17.170.000 ( = 35 MB). In the failing cases, the test is executed on 32-bit Windows with -Xcomp and -XX:+DeoptimizeALot which increase memory consumption of the VM due to extensive (re-)compilation, deoptimization and re-allocation. The test fails because there is not enough heap space to hold the String.
>> I reduced the number of threads to 32+1 and the number of per-thread iterations to 1000. I verified that this fixes the OOMEs on the failing 32-bit Windows machines.
>> Thanks,
>> Tobias

More information about the hotspot-compiler-dev mailing list