RFR: Fix jtreg test runtime/StackGuardPages/
david.holmes at oracle.com
Tue Apr 3 13:58:03 UTC 2018
On 3/04/2018 10:30 PM, Siebenborn, Axel wrote:
> Hi Mikael,
> Both tests fails because
> res = (*_jvm)->AttachCurrentThread(_jvm, (void **)&env, NULL);
> returns with an error (res != JNI_OK).
> AttachCurrentThread uses the current thread as JavaThread and allocates a java level Thread object and needs to run initializing java code (JavaThread::allocate_threadObj).
> In order to run java code, the remaining stack space is checked. There must be sufficient space for an interpreter frame, the java frame and shadow pages ( JavaCalls::call_helper() ). The default for the number of shadow pages is 10 for a release build. If this check fails a StackOverflowException is thrown.
> As we return with a pending exception the attach fails and we return JNI_ERR.
> This is a problem as we call AttachCurrentThread from a thread that we created with the default stacksize. Threads created by the jvm are created with a much higher stacksize.
> webrev_a fixes the test by providing an argument for the stacksize to pthread_create.
> webrev_b reduces the amount of shadow pages.
You can't just reduce the number of shadow pages arbitrarily. You have
to be able to pass the stackoverflow tests with the selected number(s).
> Does that make things clearer?
>> -----Original Message-----
>> From: Mikael Vidstedt [mailto:mikael.vidstedt at oracle.com]
>> Sent: Dienstag, 3. April 2018 00:01
>> To: Siebenborn, Axel <axel.siebenborn at sap.com>
>> Cc: portola-dev at openjdk.java.net
>> Subject: Re: RFR: Fix jtreg test runtime/StackGuardPages/
>> Can you please add some additional color/details to why it fails? Is it the
>> native or java variant that fails (or both)?
>> I understand that the stack is smaller with musl (I ran into that problem in a
>> different context), but I’m not sure I see why Thread.init() would fail just
>> because of that. Help? :)
>>> On Mar 22, 2018, at 3:37 AM, Siebenborn, Axel
>> <axel.siebenborn at sap.com> wrote:
>>> the test runtime/StackGuardPages/ fails, as AttachCurrentThread() returns
>> with an error. The reason is a stackoverflow while trying to run java
>>> The default pthread stack size is 80 K, much less than on other Unixes.
>>> The first fix is to check the pthread default stacksize and increase it if it's
>> less than 160K.
>>> Webrev a:
>>> However, the reason we need that much stack, just to run a single java
>> method, is the large amount of shadow pages.
>>> The second fix is just to add a flag to JNI_CreateJavaVM, to set the number
>> of shadow pages to a lower value. However, a change in globals_x86.hpp is
>> needed to allow smaller minimum for that value. Here I miss a macro like
>>> Webrev b:
>>> I'm unsure which change to use.
>>> What do you think?
More information about the portola-dev