[11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.

[Lindenmaier, Goetz]

Hi,

I'd prefer to push this.
I'm not really happy with 11 staying behind 11-oracle in the JVMCI issue.
Unfortunately there is nobody in the open community to address this.
And there are enough other changes OpenJDK 11 lacks wrt. 11-oracle.
If this gap grows big, we can no more claim OpenJDK 11 is a valid replacement
for the Oracle vm. 

So I would continue to try to take all changes that go to 11-oracle
to OpenJDK 11, too.

And as this is now ported to 11, let's push it.
Anyways, it also affects C1 and other shared code, so it might
simplify integrating follow-ups.

Best regards,
  Goetz.


> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Thursday, August 27, 2020 6:00 PM
> To: Andrew Haley <aph at redhat.com>; Doerr, Martin
> <martin.doerr at sap.com>; 'hotspot-compiler-dev at openjdk.java.net'
> <hotspot-compiler-dev at openjdk.java.net>; jdk-updates-
> dev at openjdk.java.net
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: Re: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries.
> 
> On Thu, 2020-08-27 at 16:25 +0100, Andrew Haley wrote:
> > Hi,
> >
> > On 27/08/2020 11:04, Doerr, Martin wrote:
> > > > Why is anyone backporting a P4 Enhancement? Seems weird.
> > > This is a good question in general. Personally, I'd vote for
> > > backporting fewer less important things to 11u in the future. We
> > > should better focus on 17 IMHO.
> > >
> > > However, there are some arguments for backporting this one:
> > > - Oracle has done so. There may be more backports in this area and
> > > I'd expect less effort if we have the same code in the open version.
> > > - Performance is supposed to be better. (Though I didn't measure it.)
> > > - New code is much cleaner. Let's keep in mind that we have to
> > > support it for quite a while.
> > >
> > > Are you ok with it?
> >
> > I'm unsure. While "Oracle has backported it" has been a slam-dunk
> > justification for many patches, I am concerned about the destabilizing
> > effect of the volume of patches we are processing.
> >
> > "Better performance" is not in itself justification for a backport
> > unless the improvement is really compelling.
> >
> > "Cleanups" are a red flag. The miserable history of code that has been
> > broken by seemingly innocuous cleanups is long. This is a big change
> > that affects some very delicate code, but the fact that there is
> > already a GraalVM patch we can use is quite persuasive.
> >
> > So I'm not refusing it, I want people's opinions.
> 
> It seems like a nice-to-have fix for OpenJDK 11 itself. Interest seems
> to be coming from Graal. Until there is a more compelling reason to
> backport this (other than performance for some JVMCI impl) we shouldn't
> backport this. We already have a label for these: jdk11u-jvmci-defer.
> We should apply that and re-evaluate later if needed.
> 
> My $0.02
> 
> Thanks,
> Severin