CSR Review: 8189423: Add option to disable stack overflow checking in primordial thread for use with JNI_CreateJavaJVM
David Holmes
david.holmes at oracle.com
Tue Oct 17 13:00:17 UTC 2017
On 17/10/2017 10:41 PM, Robbin Ehn wrote:
> On 10/17/2017 12:29 PM, David Holmes wrote:
>> On 17/10/2017 7:28 PM, Robbin Ehn 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)
>>
>> Yes - that allows it to impact all of our launchers as well - not
>> something I want to allow for. It opens the door for a myriad of bug
>> reports if people use this flag without understanding it's consequences.
>>
>> The aim here is to solve a specific problem, not introduce new ways to
>> break things.
>
> First, since this is broken, you would fix the issue with different
> stacksizes.
Not sure what you consider "broken". The current approach causes a
problem for runtimes that want to do their own stack guards. The
proposal is to allow them by giving a flag to turn ours off - but only
for the primordial thread, as that is where the problem lies.
> And secondly, I think the solution to that is to move all 'text' options
> to the launcher and have the CreateVM taking a data structure with
> pre-parsed options. And let the launcher choose which options to expose
> to the end-user. Meaning our own java launcher would never expose this
> option. (but this is much bigger discussion)
Let's not start to envisage a complete re-design of how you might
communicate arguments between a host process and the VM. Please.
> Would the option would skip adding guard to any other thread calling
> CreateVM?
> If not, have the option really the correct name?
>
> E.g. -XX:+DisableCreateVMThreadGuardPages ?
The option would ONLY skip for the PRIMORDIAL thread of the process when
it loads the VM - hence it has exactly the right name. I specifically do
not want to allow this for an arbitrary thread that happens to do the
loading of the VM.
Thanks,
David
> Thanks, Robbin
>
>>
>> David
>>
>>> 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