[8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u

[Gil Tene]

> On Apr 12, 2019, at 12:38 AM, Andrew Haley <aph at redhat.com> wrote:
> 
>> On 4/12/19 7:11 AM, Gil Tene wrote:
>> 
>> Since there is a time crunch on this, and no new update has been
>> posted in the thread in the past ~35 hours in response to the below,
>> we will proceed with the assumption that the plan in the e-mail from
>> Andrew Hughes below (to include the pushed patch in an expected
>> final 8u212-b04) is going forward. Lets not change from that at this
>> late point.
>> 
>> In future cycles, I think that we probably need a bit more time for
>> review and input before making such a call so close to the final
>> release. We went from first identification
>> (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009074.html
>> ) to decision
>> (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009086.html)
>> in under 7 hours, which occurred between 1:39AM and 8:26AM Pacific
>> time.
> 
> We're not always the masters of our destiny. We got notice of this
> regression very late in the cycle and I had to make a judgment
> call. There was time to apply the backport, just, and it was better to
> get it in than spend time discussing whether we should; there is a lot
> of latency on this list and such a discussion would surely have led to
> failure.

You are the project lead (which I am happy for) and the
decision is yours. As I note above, I do not wish to have
it changed at this point. I also fully recognize that
judgement calls need to be made, and that not all will be
perfect. We stick with them and move on.

My note above (and below) is seeking to improve similar
situations In future cycles, and not as a critique or
challenge to the decision already made. A couple of
things to note that may help us potentially do better
next time:

1. The choice itself was driven by wanting to “avoid a
performance regression between OpenJDK 8u212 and
Oracle's 8u212”. At least that’s what the open discussion
here shows. I believe that the informational basis
motivating the choice was a bit off (see my previous
email on the thread), and that we would have ended up
with a different choice if we had more eyes looking at
It, or more time to dig and notice that Oracle is (likely)
not Including the same patch until a later BPR.
(Again, not looking to change it now, but looking to
keep the situation in mind next time we are up against
a similar last minute decision)

Potential improvement for future cycles:
Both more time (let 24 hours pass so all time zones
are in) and a hard line, e.g. 7 days before the release,
where “nothing more goes in unless it’s a newly
discovered regression introduced by changes made
since the last release”, would separately help avoid
at least some of these crunch-time choices.
[in this case either mechanism would likely have ended
up with you making a different choice, as we would have 
either discovered the additional detail of the BPR,
or determined that this is not a regression introduced
by changes made since the last release]

2. Once I replied on the thread (within 4 hours) , the
choice itself was in “limbo” (at least for us), with 6 days
before the anticipated release. I ended up proactively
“backing off” of the subject purely for timing reasons
(after 1.5 days) in order to get out of the this “limbo”
state. Had this been one week earlier, the discussion
would likely have continued with a potentially different
outcome.

Potential improvement for future cycles:
Declaring some line (e.g. 5 day or 7 days before release)
where subsequent not-yet-visible patch inclusion
decisions become final upon declaring them would be
useful in the future, so that we can avoid some limbo
situations so close to the line.

> 
> -- 
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671