JEP 270: Reserved Stack Areas for Critical Sections

[Frederic Parain]

Hi Volker,

My comments are in-lined below.

On 24/09/2015 09:05, Volker Simonis 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.

The mechanism requires that the reserved area and the yellow zone could
have different protections. On a 4KB page system, the reserved area
and the yellow zone are necessarily on two distinct pages.

It seems that Linux on PowerPC has a special system call to set
access permissions on individual 4KB subpages on systems configured
with a page size of 64KB:

http://man7.org/linux/man-pages/man2/subpage_prot.2.html

I'm not familiar with Linux on PowerPC, but it might be possible
to use this system call to implement the reserved area and the
yellow zone (and even the red zone) using a single 64KB page
but with different subpage permissions.

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

No static analysis tools have been used. The number of critical
sections considered for annotation is very limited and the code
sections themselves are very small (as critical sections should be).
The analysis has been done by humans. But yes, there's a risk here
if the annotation is used on a code section that is not fully under
our control: call back to user code, call to native code, call
to overridable methods. In such cases, the annotation should not
be used, but I don't think there's a way to enforce it. At least,
we could make this point explicit in the documentation.

Regards,

Fred

> 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