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