RFR: JDK-8282405: Make thread resource areas signal safe [v5]

[Thomas Stuefe]

On Fri, 4 Mar 2022 06:34:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The signal handler doesn't call foo(), it just happens to call some code that also uses the data structure X. If X expands while on the alt-RA and doesn't contract again, then X will have a chunk that still refers to the alt-RA when we have switched back to the primary-RA.
> 
> Ideally such things can never happen and the alt-RA is always unused by the time the signal handler returns, but without looking at the kind of RA usage that might occur from the signal handler, I can't say whether it will be clean this way or not.
> 

Okay, I think I understand. Things like the former implementation of stringStream, which used an internal buffer allocated from RA, which could grow on demand. We switched stringStream to C-heap allocation for the very reason that this is broken by design.

Pointers allocated from RA should not escape the boundary of the ResourceMark it was allocated in, because the ResourceMark could unwind the RA and deallocate the chunk the pointer points to. That also means that you should not hand a on-demand-growable structure up and down the stack unless you are very sure that you don't cross a RM boundary. That excludes using RA memory as back buffers in utility objects that are handed down the stack naturally, like outputStream.

My argument is that this is a broken pattern, and it was one before my patch too. Switching the underlying RA itself is really not different from crossing a RM boundary. Look at it like this, if your allocation escapes an RM, it does not matter whether the Chunk it lives in is part of the secondary RA or part of the primary RA, it will get cleaned out and your allocation becomes invalid either way. 

> JDK-8265150 is a great example as it shows that allocating from the RA in a signal handler via AGCT is fundamentally broken. Even with the alt-RA do we still not have the ThreadCritical problem?

Definitely. Its interesting that such a shaky concept became the cornerstone of a popular product like the async profiler.

> 
> I don't want the perfect to be the enemy of the "good enough" here, but do want to be sure the cost:benefit ratio is sufficiently small to make this worthwhile.

Hmm, I think it is. I know our sporadic crashes on PPC in the async profiler disappeared with the use of secondary RAs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7624