JEP 270: Reserved Stack Areas for Critical Sections

[Volker Simonis]

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