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

[Vladimir Kozlov]

Perfect.

thanks,
Vladimir

On 9/20/16 1:27 AM, Tobias Hartmann wrote:
> 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:
> http://cr.openjdk.java.net/~thartmann/8166046/webrev.01
>
> 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,
> Tobias
>
>> 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
>>>