JEP 270: Reserved Stack Areas for Critical Sections

[Frederic Parain]

Volker,

The delayed StackOverflowError provided several information
about what happened:
   - it has a special message "Delayed StackOverflowError due
     to ReservedStackAccess annotated method" so user can
     know that it is a delayed StackOverflowError and not
     an ordinary StackOverflowError
   - the call stack provided with the delayed StackOverflowError
     is generated at the point where the error is thrown, not
     the point where access to the reserved area has been granted,
     So it indicates exactly where the execution has been interrupted
     (when C() returns in your example).


Note: The warning message printed by the JVM is generated and printed
when the reserved area is hit for the first time, thus it doesn't give
information about where the delayed StackOverflowError is thrown.

Regards,

Fred

On 24/09/2015 15:36, Volker Simonis wrote:
> Hi Frederic,
>
> I understand all this. My question is if the delayed
> StackOverflowException is not misleadingly pretending that the
> execution was interrupted at a specific point of the program while the
> program actually safely passed that point. When we have
>
> final void critical() {
>    A();
>    B();
>    C();
> }
>
> and B() would trigger the StackOverflowException() a smart caller of
> 'critical()' might assume that C() hasn't been executed (and maybe
> handle that appropriately). But with the new reserved stack area
> feature, C() actually has been successfully executed. Isn't this
> something we must be aware of or do I misunderstand something here?
>
> Thanks,
> Volker
>
> PS: and thanks for the hint with subpage_prot(). I haven't been aware
> of that syscall until now but it may be worth investigating it in more
> detail.
>
>
> On Thu, Sep 24, 2015 at 3:16 PM, Frederic Parain
> <frederic.parain at oracle.com> wrote:
>> Hi Volker,
>>
>> The point here is that the reserved area aims to protect some
>> data structures from corruption, not to save the faulty thread.
>> A thread that hits its reserved area is an abnormal situation.
>> The goal is not try to save the thread by giving it more stack
>> space, because in most cases it will simply continue to consume
>> stack space and reach the new limit anyway. The goal is to
>> try to throw the StackOverflowException at the more appropriate
>> point of execution in order to mitigate damages.
>>
>> Throwing the StackOverflowException is the behavior expected
>> from the JVM when a thread has consumed all its stack space.
>> The exception is thrown to notify the thread that it has
>> reached its stack limit. The warning printed by the JVM can
>> help to diagnose the issue because exceptions are often catch
>> in library code (see JDK-7011862). But the warning is not
>> sufficient because the Thread cannot see it.
>>
>> Regards,
>>
>> Fred
>>
>>
>> On 24/09/2015 10:15, Volker Simonis wrote:
>>>
>>> I also have problems understanding the following part:
>>>
>>> "If the protection of the reserved zone has been removed to allow a
>>> critical section to complete its execution, the protection must be
>>> restored and the delayed StackOverflowError thrown as soon as the
>>> thread exits the critical section."
>>>
>>> Does this mean that after the critical section completes the VM will
>>> still throw the StackOverflowException that would have been thrown if
>>> we did not had the extra reserved space? Isn't this misleading?
>>> Wouldn't user code which catches this exception expect that the
>>> critical section was not executed till the end because of the
>>> exception? Why do we need to throw the delayed StackOverflowException
>>> in that case? Wouldn't the warning which will be printed be enough
>>> information (and semantically more correct compared to throwing an
>>> exception)?
>>>
>>> Regards,
>>> Volker
>>>
>>> On Thu, Sep 24, 2015 at 9:05 AM, Volker Simonis
>>> <volker.simonis at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> that's an interesting JEP. Thanks a lot for the detailed analysis and
>>>> problem description.
>>>>
>>>> I see a little problem with the additional zone you want to introduce.
>>>> This zone must be page-size aligned and at least one page. But on
>>>> PowerPC it is not uncommon nowadays that Linux runs with a default
>>>> page size of 64K. Wasting another page for the new zone would result
>>>> in 3*64K = 192K overhead for the three zones. Not sure about other
>>>> architectures but it seems that at least AArch64 supports a 64K
>>>> default page size as well. Itanium even has two stacks (register and
>>>> memory) which doubles the trouble.
>>>>
>>>> Taking all this into account, have you considered using a part of the
>>>> available yellow zom as reserved stack are for critical sections? If
>>>> you run with a page size of 4K you could just increase the yellow zone
>>>> by the required number of pages, otherwise you could just use it as is
>>>> (64K should be enough for a critical section according your analysis.
>>>>
>>>> We must also somehow ensure that critical sections can not call
>>>> arbitrary user code, otherwise the stack usage of the critical section
>>>> will be unbound. Did you use some kind of static analysis tools to
>>>> check for this?
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>> On Thu, Sep 24, 2015 at 2:25 AM,  <mark.reinhold at oracle.com> wrote:
>>>>>
>>>>> New JEP Candidate: http://openjdk.java.net/jeps/270
>>>>>
>>>>> - Mark
>>
>>
>> --
>> Frederic Parain - Oracle
>> Grenoble Engineering Center - France
>> Phone: +33 4 76 18 81 17
>> Email: Frederic.Parain at oracle.com

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com