RFR(S) 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section

[Gustavo Romero]

Hi Martin,

Thanks a lot for reviewing.

On 03-08-2016 10:17, Doerr, Martin wrote:
> 1. A future C++ compiler or runtime code may use HTM, too. Should your new code get invoked in such a case? Or is it only for transactions which were started in the code cache (UseRTMLocking)?
I see. Initially I was just thinking in the case of a transaction started
in the code cache, but it's fine for a runtime code to use HTM and generate
a signal in the middle of it as we simply return the control back to the
HTM abort handler (new webrev below).

For a C++ compiler with TM (PPC64), I'm unable to foresee the final
implementation of the atomic blocks and how it would affect the signal
handler in the specific case of PPC64 (where we have two contexts due to
the additional suspend TM state). Anyway I believe the abortion in an
atomic block would yield an event similar to the runtime code, so in
that case it's already covered.


> 2. I was wondering why you only check for zombie_not_entrant. There are many cases in which a signal may occur during a transaction (e.g. implicit null check, range check, stack overflow check, safepoint poll, ... and possibly more in the future). What about them? I guess continuing execution in the context of the 'treclaim'ed transaction is incorrect.
Sorry, I forgot all those cases, hence yes, it's incorrect to continue the
execution in the second context (or speculated state).


> 3. I think reporting errors which occur during transactions is cool. But if it's too complex, I could live without it. Other platforms don't support this either (they just abort by hardware).
Yes, I was really focused on finding a way to report errors that could
occur during transactions. I think it would be cool, nonetheless I agree,
it's too complex (also as an implication of all the cases mentioned in 2.).


> I was not involved in the earlier discussion. Maybe I missed something.
No, you did not miss anything. Thomas raised the question on if two
contexts exist, then which one would be correct/valid for error reporting.
My try on using the second context to report precisely the root cause of an
abortion was inspired by his question.

new webrev:
http://81.de.7a9f.ip4.static.sl-reverse.com/8162369/v2

Thanks and best regards,
Gustavo