RFR: 8269476: Skip nmethod entry barrier if there is no oops in the jit code [v2]

[Erik Österlund]

On Tue, 29 Jun 2021 07:36:04 GMT, Andrew Haley <aph at openjdk.org> wrote:

> On 6/29/21 8:03 AM, Erik Österlund wrote:
> > 1) When this was introduced, we did not see the overhead of nmethod entry barriers in performance profiles. Did you see any improvement with the patch?
> 
> This is a LoadLoad fence at the start of every method followed by a load
> with a dependent branch. If there wasn't a significant hit in the profiles
> I wouldn't believe the profiles. Even adding code that doesn't appear to slow
> things down uses additional speculation resources.

My main concern is that I am not convinced that eliding nmethod entry barriers is sound. It really isn't all about protecting oops found in the machine code as I explained previously. There is a lot more to it. Therefore I would like to at least have some convincing number showing that such an optimization effort is worthwhile.

If you are looking at ways of getting rid of the loadload, I have a scheme that can elide it if you are interested. I discussed it with Stuart when he was prototyping how to build these barriers, but I think he concluded we didn't need such optimizations in the end. It came with some more complexity. That's why I am curious if you have numbers suggesting the opposite. Because if so, I have a better idea to target the loadload in particular, witout violating our invariants and still being correct.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4610