RFR: 8257731: Remove excessive include of stubRoutines.hpp
David Holmes
david.holmes at oracle.com
Sun Dec 6 13:19:31 UTC 2020
On 6/12/2020 9:23 pm, Claes Redestad wrote:
> On 2020-12-06 11:15, David Holmes wrote:
>>>
>>> And since there's likely going to be some churn happening in tandem
>>> in both mainline and stabilization fork in the coming weeks, wouldn't
>>> it be better to get changes like these pushed _before_ rather than
>>> right after the JDK 16 stabilization fork is created? The second best
>>> option might be to hold off with large cleanups/reshuffling until
>>> RDP2 starts.
>>
>> I think the point was to defer to this to be 17 only so no churn at
>> all in 16 RDP1 or RDP2.
>
> Seems we're talking past each other:
>
> - The churn I'm referring to is the regular weeks (or months) of bug
> fixing and forward-porting that happen after a stabilization fork - not
> some highly unlikely churnpocalypse resulting from this patch in
> particular.
I've no idea what you mean by this.
> - Getting this into 17 right after the stabilization fork means we have
> an increased risk of merge conflicts etc, which means the automatic
> forward porting of pushes to 16 will be in peril.
True this could impact the form of changes in 16 versus 17.
> So what I'm suggesting here is to either:
>
> - Get this tested out on all platforms and pushed _now_ to reduce risk
> of conflicts during 16 stabilization
>
> OR
>
> - Wait until some time after 16 forks to get past the 16 stabilization
> churn to minimize risk of conflicts during stabilization that might
> prohibit automatic forward porting.
>
> I have a preference for the former.
Okay. I also prefer the former. The previous issue with this kind of
patch was lack of testing, so as long as we have adequate testing this
kind of refactoring should be a non-issue.
Blocking this kind of change effectively introduces a de-facto RDP0.
David
-----
> /Claes
>
>
>
>
More information about the hotspot-dev
mailing list