[crac] RFR: Introduce per-Priority Context with different policies

[Anton Kozlov]

On Thu, 25 May 2023 06:22:08 GMT, Radim Vansa <duke at openjdk.org> wrote:

>> Apparently you mean why the global context implementation has been changed, not why the test has to use an explicit implementation.
>> 
>> Honestly I did not realize the global context properties were changed in #60, so I just want to revert that for a while. This was rather big change. And that deserved a separate line in the javadoc, which is btw the specification, not the tests (although they are definetely useful). I lean toward using BlockingContext, but want to think a bit more about that, with the spec change.
>
> Yes, the behaviour should be specified through javadoc but that does not say anything about registration when the checkpoint is proceeded. Per your logic that behaviour is unspecified and hence the change doesn't matter. Moreover, you've explicitly asked to postpone javadoc changes into #65 which did not get review in 2 weeks.
> 
> Rather than changing implementation forth and back you could explain why certain behaviour is more useful. Now you've removed a test for certain codepath - creating resource in global context - if you think it should behave in a different way you should keep it and assert different outcome.

Having that we've met so many self-deadlocks after the blocking was introduced, it seems it will happen with the users who will run into the same problem with the global context, which we suggest by default. I'm still trying to untagle with consequences of #60, with this PR in particular. You can see the policy for the global context is going to be specified by a single line of code. Anyway sorry for reviews taking so long. You can simplify reviewer job by separating functional and non-functional changes. Rephrasing javadoc for readability is non functional, changing the meaning is functional.

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

PR Review Comment: https://git.openjdk.org/crac/pull/74#discussion_r1209468675