Re: [9] RFR (S): 7177745: JSR292: Many Callsite relinkages cause target method to always run in interpreter mode

What I would like to see is for users to feel free to use CallSites with any amount of mutability, and have the JVM pick a good strategy for speculating and optimizing through CS target bindings. By "good" I mean that, if the CS is not megamutable, you get the performance comparable to an

Re: [9] RFR (S): 7177745: JSR292: Many Callsite relinkages cause target method to always run in interpreter mode

On Jan 20, 2016, at 4:13 AM, Remi Forax wrote: > > I understand that having the VM that may always recompile may be seen as a > bug, > but having the VM that bailout and stop recompiling, or more generally change > the compilation strategy is a bug too. As you can guess

Re: [9] RFR (S): 7177745: JSR292: Many Callsite relinkages cause target method to always run in interpreter mode

I was going to say it is unlikely to matter in production cases but might well hit test code which does extensive meta-programming, but actually, since it¹s a question of invalidations across _all_ sites, rather than any single one I think it might make a difference. I¹ll need to take a look at

Re: [9] RFR (S): 7177745: JSR292: Many Callsite relinkages cause target method to always run in interpreter mode

John, Chris, thanks for the feedback. I don't think it is only about microbenchmarks. Long-running large applications with lots of mutable call sites should also benefit for this change. Current JVM behavior counts invalidations on root method, so nmethods with multiple mutable call sites

Re: [9] RFR (S): 7177745: JSR292: Many Callsite relinkages cause target method to always run in interpreter mode

@oracle.com> > À: "Vladimir Ivanov" <vladimir.x.iva...@oracle.com> > Cc: "hotspot compiler" <hotspot-compiler-...@openjdk.java.net> > Envoyé: Mercredi 20 Janvier 2016 00:37:29 > Objet: Re: [9] RFR (S): 7177745: JSR292: Many Callsite relinkages cause >