RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u

[Gil Tene]

> On Jul 8, 2020, at 4:07 PM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> On Wed, 2020-07-08 at 22:35 +0000, Gil Tene wrote:
>> 
>> 
>>> On Jul 8, 2020, at 2:58 PM, Roman Kennke <rkennke at redhat.com>
>>> wrote:
>>> 
>>> ...
>>> In other words: what exactly is it that you want to prove then? I
>>> don't
>>> understand it.
>> 
>> I'm not sure I understand it either. ;-)
> 
> Haha, ok right :-)
> 
>> I'm basically asking the "if we prove it now", how do we know that
>> the
>> same holds later?" question.
>> 
>> Delaying some big impact by one update is clearly not the goal you
>> are proposing.
> 
> I don't understand this sentence (but it's quite late here...)
> 
>> I believe we agree that the quality you suggest would need to be
>> retained into future
>> builds. Having nothing to prevent it from breaking (e.g. by accident)
>> is probably
>> dangerous. So the question becomes "how do we ask the question of
>> whether or not
>> we still have not introduced any differences?" in future updates.
> 
> Ok.
> 
>> Let's start from the assumption that we can prove something now (and
>> I
>> do think we should be able to find a mechanical thing to do that).
>> That will show
>> that the quality we seek to keep has been kept at a point in time...
> 
> Yes. Let's assume that. (As an aside, if you'd actually look at the
> patch, I hope you'd find it quite obvious that it does the right thing.
> And you might be surprised how relatively few such changes we actually
> have.)
> 
>> For as long as the statement of "without Shenandoah enabled, the
>> build
>> does not have any actual code bits related to the Shenandoah back-
>> port"
>> needs to hold, we need a way to show that the same still holds,
>> Either by
>> proving that the original proof still holds in the presence of
>> changes, or
>> by re-proving it somehow.
>> 
> 
> Let me elaborate a little bit on my experiences with backports, and
> mixing both Shenandoah and non-Shenandoah backports.
> 
> In the many months since we maintain Shenandoah in our 11u, the
> overhelming majority of Shenandoah-related backports did not touch any
> shared code at all. That's because the existing GC interfaces isolate
> GCs really well in 11u. The few occasions where we did change shared-
> code was 1. When we switched to LRB. We would not usually backport such
> drastic changes, but it seemed prudent here, because it did actually
> decrease the shared-code exposure drastically. 2. in preparation for
> this upstreaming patch - more pruning and isolation of shared-code
> changes.
> 
> In the very rare situations where a backport would require shared-code
> changes (I can't actually remember any, apart from the two that I just
> mentioned), we carefully consider if it's actually necessary to
> backport. For example, we have not backported concurrent class-
> unloading support to 11u precisely because it would require
> (significant) changes outside of Shenandoah. *If* a critical backport
> (say, a bugfix) requires changes outside of Shenandoah, it would have
> to be properly guarded by the same means as we do in the proposed
> upstreaming patch. We - the Shenandoah team - would be aware of that
> and mention it in relevant reviews. It would also prominently show up
> in a patch because it has files without 'shenandoah' in their path
> names. And from there, it's a matter of carefully considering,
> reviewing and testing it. I don't think this would silently sneak in
> somehow.
> 
> I can't think of a situation where we ever had the reverse problem: a
> shared-code change touching on something Shenandoah-related.
> 
> Also, while we did have a flurry of Shenandoah-related backports in the
> past, because of stabilization and new features (e.g. LRB and friends),
> this is most likely not going to continue into the future. I expect
> less Shenandoah-backporting traffic, basically limited to bugfixes and
> improvements that don't touch shared-code. We have a couple of features
> on our todo list for later JDKs, but none of them sound like candidates
> for backporting.
> 
>> The notion that our normal review processes will catch everything
>> that can break
>> that initial prooved state seems a bit optimistic to me. The review
>> process will be
>> well intentioned, and we'll try to tag things right, but one mistaken
>> application or
>> move of code across ifdef lines, or integration of some mis-tagged or
>> unnoticed tag
>> thing into shared code will break the statement…
>> 
> 
> How is that any different from the situation that we already have?
> Hotspot code already has similar #ifdefs sprinkled all around, e.g. for
> other GCs, for JFR, platform #ifdefs, and so on. How is the situation
> different for Shenandoah, why do we need special rules or process or
> even proofs for that? As far as I can see, our current high-standard
> development and review practices already cover it very well.
> 
>> I believe that we can avoid this once, at the start, with a
>> mechanical proof. Can
>> we keep it up? What sort fo rules or invariants can we come up with
>> that we can
>> use to verify and show that the quality we seek to keep has been kept
>> through later
>> updates?
> 
> Well yes, the usual proper care that everybody is taking in making the
> backports, reviewing the backports, testing it, etc.
> 
>> Let's try to think of some….
> 
> As long as we don't know what the exact question/problem even might be,
> we can hardly come up with an answer/solution.

I'm not trying to be difficult here. I'm just going with the basic line
of logic, and looking for a way to implement it.

IF we can PROVE that the actual code built is not changed from the
prior-to-this-change code when built without (--with-jvm-features=-
shenandoahgc), THEN there is no basis to argue that the code change
creates any form of change-related impact for existing users and distros
as they update to inherit new upstream changes for bug fixes and security
updates.

I agree with that statement. And IF we can make it true, I must obviously
remove my reservations to adding a new collector to trhe 11u upstream
for use in distros that want to build it in, as necessity no longer comes into
play in the argument. We would not have consider the change from the
point of view of other distros build without (--with-jvm-features=-shenandoahgc),
and of their users: we would have PROVEN that they are not affected in
any way.

That is the key point of agreement, and a powerful argument. It is a way to
remove my original concerns.

To build to something useful from there, I'm looking to see how we can both
establish the "no change" situation (prove it), and to maintain that situation
as true over time (prove it for the next update).

Unless we can prove it for the next update, all we would have done is delay
the feared  impact to other downstream distros and users by one quarter. And
that would not remove any of the necessity-based concerns.

If there is a viable proof for the stating point, it seems like there should be a
way to continue proving the same over time. And I think we should look for
some technique that would provide that. Various "we will be very careful after
the first change" arguments, without a means to prove things, don't provide
more comfort for the same reason the "we have been very careful" ones for
the original change don't: without a proof mechanism that shows that there
is no change, we go back to the original "change in an LTS requires a level
of necessity" argument.

As for the difference from other things we review when doing backports into LTSs:
I don't know of other examples where we have tried to prove that something has
zero changes in code in order to allow it in over concerns, let alone continually
review to maintain that zero changes statement. It's new territory.

I did not propose the proof logic as basis for inclusion regardless of necessity, I
just accept it as a possible path, and I'm going with the "what if we could prove it?"
logic to see if we can make it work. If we switch back to "but we can't prove it" or
"we shouldn't need to prove it" in the middle of looking for that, then that just
brings me back to my original concerns.

— Gil.