Scoped variables

[Remi Forax]

Just to add another possible use case for valhalla,
scoped variables can allow to pass the reified type arguments of a generic method call out of the band (not directly as argument on stack) thus may allow to come with a backward compatible way to call generic methods, at least in the interpreter.

Rémi

----- Mail original -----
> De: "Andrew Haley" <aph at redhat.com>
> À: "Doug Lea" <dl at cs.oswego.edu>, "loom-dev" <loom-dev at openjdk.java.net>
> Envoyé: Jeudi 6 Décembre 2018 11:27:38
> Objet: Re: Scoped variables

> On 12/5/18 1:24 PM, Doug Lea wrote:> On 12/5/18 5:15 AM, Andrew Haley wrote:
>>> About half of the code in ThreadLocal.get() is because of bounds
>>> checks, indirections, type checks, and null pointer checks.
>>
>> Yeah, welcome to my world. It takes code that people think is weird/ugly
>> to express these in ways that are still pretty fast. I haven't tried
>> recently with ThreadLocal, but I once checked that similar constructions
>> in j.u.HashMap were about as fast as Unsafe cheats. So I don't think
>> you'd see significant speedup recoding natively. But please prove me wrong.
> 
> That's the plan. :-)
> 
> At some risk of teaching my grandmother how to suck eggs, here goes:
> 
> There is a fallacy I see a lot in discussions about Java performance,
> and it goes like this. Someone will add a little extra code to
> something, measure it in jmh, and point out that performance hasn't
> worsened.  Apparently they added this code, measured, and discovered
> that it makes no difference to execution time! So it must be OK.
> 
> But, in fact, it's not OK. What has happened is that the CPU has
> considerable parallelism, and when measuring execution time in a jmh
> benchmark most of that parallelism is unused. This is deliberate: jmh
> goes to great lengths to isolate benchmark code so that it and nothing
> else runs during the timing interval. So, adding code sometimes adds
> no time at all: the new code just runs in parallel with the rest if the
> benchmark. Of course, this doesn't hold when running Java applications
> because this extra code elbows out of the way application code that
> would otherwise run in parallel.
> 
> Efficient systems are composed of thousands or millions of tiny
> optimizations, each one of which is too small to contribute any
> benefit which can be seen above the noise.
> 
>>> The null pointer checks facilitate lazy initialization, which we
>>> don't need in scoped variables.
>>
>> Well, something somewhere would surely null check result, so it's hard
>> to imagine this helping much.
> 
> There's no need to do it. See above. :-)
> 
>>> There are some because of the use of WeakReferences, which scoped
>>> variables won't need because they disappear when the scope exits.
>>
>> Not using Weak Refs would be the biggest win. Lots of simplifications
>> would be possible. But would require a new API.
> 
> Yep. And right now scoped variables are a new API. It's a chance
> really to get it right, for once and (hopefully) for ever.
> 
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671