RFR 8157592: StackTraceLogging fails with stack overflow on 32-bit Windows

[David Holmes]

On 11/06/2016 5:05 AM, Coleen Phillimore wrote:
>
>
> On 6/9/16 9:08 PM, David Holmes wrote:
>> Hi George,
>>
>> On 10/06/2016 4:09 AM, George Triantafillou wrote:
>>> Please review this small change to fix test failures on 32-bit Windows.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8157592
>>> Open webrev: http://cr.openjdk.java.net/~gtriantafill/8157592/webrev/
>>> <http://cr.openjdk.java.net/%7Egtriantafill/8157592/webrev/>
>>>
>>> TestThrowable.java: Added catch for intermittent StackOverflowError
>>> errors on 32-bit Windows.
>>
>> This does not seem to be addressing the problem - why do we suddenly
>> start getting SOE when running this test? I asked that question in the
>> bug report. If something has changed to trigger this then we need to
>> ensure that change was intended/desirable and then look at how to
>> adjust the test - not simply catch the SOE and ignore it.
>
> Well it's not a very robust test.  I wrote it.  On 32 bits, it's
> possible that the compiler didn't kick in in time to run the recursive
> method.  The c2 compiler would generate code that uses almost zero
> stack.  With interpreted, there is some stack usage. The test could have
> been on the borderline of that.  I think it's prudent to accept stack
> overflow, especially if the default stack size increases or decreases
> over time.

I think we need to be certain that the test was borderline before and 
that it is not a case of something else suddenly consuming copious 
amounts of stack. And if it is borderline then reduce the stackdepth to 
get away from that border. I don't see why this test needs to go 
anywhere near SOE territory.

David

> Thanks,
> Coleen
>
>>
>> Thanks,
>> David
>> -----
>>
>>
>>> StackTraceLogging.java: Removed unused updateEnvironment method.
>>>
>>> Tested locally on 32-bit Windows as well as RBT.
>>>
>>> -George
>>>
>