Reference-default style

John Rose john.r.rose at oracle.com
Fri Feb 7 23:26:17 UTC 2020


On Feb 7, 2020, at 2:39 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
>> On Feb 7, 2020, at 3:05 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> - Supertypes, methods (including static methods, and including the static "constructor" factory), and static fields are lifted onto the ref projection.
> 
> This deserves highlighting: in theory, there's nothing wrong with putting all of an inline class's methods in an abstract superclass. In practice, I'm curious to know whether we take a performance hit, and if so whether it's straightforward to optimize away.
> 
> (And if there *is* a significant performance penalty, is it so bad that it's impractical to *ever* make serious use of superclass or superinterface methods in performance-sensitive contexts? That may be okay, but it's something authors will want to understand.)

Putting something in a surprising place has surprising penalties, sometimes.
But, the JVM is designed from the ground up to manage single inheritance
code sharing extremely well.  I don’t think there’s much of a performance
penalty here for putting code on a superclass rather than a subclass.

That said, putting code in a surprising place sometimes leads to surprises.

Using interface default methods is significantly riskier, as I implied in my
previous comment.

> I also kind of wonder if there are some code paths in Hotspot that will never get seriously exercised if javac never invokes a method declared in an inline class. (Not really an argument against this strategy, just an observation.)

Good observation.  We could see “surprises”.

Basically, the two classfiles are logically one compilation unit, so it should
be OK to put anything from the source file in either half-bucket.

(To remind everyone:  We are using two half-buckets rather than one bucket
mainly so that Optional can be migrated.  If it were just supporting V? then
we’d use an empty marker type, I think, probably just an interface.)

I’m not sure exactly why I feel queasy about hollowing out the V.ref,
and that’s probably because my “anti-surprise heuristic” (aka. spidey
sense) is responsible, and such heuristics can’t every say much more
than “I’ve got a bad feeling about this”.  But a rarely used code path
is one door that surprises can pop through.  :-S

— John




More information about the valhalla-spec-observers mailing list