Scoped variables

[Andrew Haley]

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