CSR Review: 8189423: Add option to disable stack overflow checking in primordial thread for use with JNI_CreateJavaJVM

Thomas Stüfe thomas.stuefe at gmail.com
Tue Oct 17 09:46:35 UTC 2017


On Tue, Oct 17, 2017 at 11:28 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:

> My understanding from prior discussion (ie when we fixed the 2MB stack
>> limit) is that it doesn't work for them to use a new thread for the JVM.
>> The change to support anything but unlimited stack size also helped (and
>> the 8M limit when 'unlimited' is tolerable) but really they just want a
>> simple way to say "please don't bother with stack guards, I can deal with
>> that myself".
>>
>
> Is there a problem I'm not seeing to extends this to all attaching threads?
> E.g. -XX:+DisableAttachingThreadGuardPages (more useful option I would
> say)
>
>
+1 for that. This would be easy to understand and more useful. I might want
to skip java stack guard creation for reasons beyond issues with the
primordial thread.

I also like the idea to specify this on a per-thread base when calling
AttachCurrentThread(), though I guess this is more complicated due to API
changes.

Thanks, Thomas




> Thanks, Robbin
>
>
>
>> This is intended to be a very simple, very specific proposal. I suppose
>> it could be flagged as "experimental" if we wanted the flexibility to do
>> something different later. But I don't see that being on the cards.
>>
>> Cheers,
>> David
>>
>>
>>> Thanks Robbin
>>>
>>>
>>>> Kind Regards, Thomas
>>>>
>>>>
>>>>
>>>> On Tue, Oct 17, 2017 at 9:22 AM, David Holmes <david.holmes at oracle.com>
>>>> wrote:
>>>>
>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8189423
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189170
>>>>>
>>>>> Could I please have a reviewer for this CSR request so I can
>>>>> fast-track it.
>>>>>
>>>>> Comments on the proposal are of course welcome.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>


More information about the hotspot-runtime-dev mailing list