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

[David Holmes]

Hi Robbin,

On 17/10/2017 7:15 PM, Robbin Ehn wrote:
> Hi,
> 
> On 10/17/2017 10:04 AM, Thomas Stüfe wrote:
>> Hi David,
>>
>> Just some notes:
>>
>> - I am confused about the "primordial thread" naming; I always understood
>> the primordial thread to be the thread running main(), not the thread
>> invoking JNI_CreateJavaVM. I always used this term in this way for AIX
>> related problems. How about "VM-Initializing thread"?
> 
> That is how I also have interpret it.

See my response to Thomas.

>>
>> - Would this not also be a useful feature for other threads attached 
>> to the
>> VM (AttachCurrentThread), as those threads may use a different 
>> SO-handling
>> scheme too ?
> 
> This is much bigger problem imho. In a product I work with we had 
> several different stack-sizes on attached threads.
> E.g. a 3rd party library might have created a thread which you want to 
> attach for a jni call.
> 
>>
>> Other than that, I think this is a useful addition. Would have helped me
>> before on AIX (see https://bugs.openjdk.java.net/browse/JDK-8179327)
> 
> Since we had similar problems, we used the advice do not call 
> CreateJavaVM with a thread you care about.
> Just spawn a new thread and call CreateJavaVM, not sure if that is worth 
> having an option for?
> 
> I much rather have an option that say do not try to figure out 
> stacksize, because you can't.
> Alternative you should have the option of attaching individual threads 
> with different stacksizes.
> 
> It's also very confusing when you are using a 3rd party library which 
> require large stacks.
> A normal unix user would just set ulimit -s 32768, but you would also 
> need to set Xss to 32M.
> A not set Xss should be the same value as pthread create uses.
> 
> So my opinion is that R can fix this with a new thread for CreateJavaVM 
> (temporarily) and we should spend some time figuring all this out before 
> adding a new option?

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".

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
>>>