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

[Tobias Hartmann]

Thanks, Vladimir.

Best regards,
Tobias

On 20.09.2016 18:58, Vladimir Kozlov wrote:
> 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
>>>>