I need to do many more additional examples offline.
I appreciate your trying to make overriding of forwarders simpler for the jvm.
I would like to continue to explore the option having the jvm do the
calculation of overriding
both direct and indirect forwarders until we’ve worked more examples.
If we can find a way to do it, it helps with backward compatibility
- old clients with old receivers don’t go through adaptors - so they miss
adaptations
that could either throw an exception or potentially lose data through narrowing.
- same issue for reflection - Class.getDeclaredMethods() which just returns
local methods
- would be nice if we could not lose existing method names here
I am also exploring invoke local with explicit local name of method - so we can
try
to reduce loops - I believe there will be steps at which we will need to
identify loops and throw
exceptions or not create a reverser.
That said, it is getting more complex, so glad you are exploring alternatives.
Link below spells out a bit more the rule I am exploring for creating reversers,
with both the example below and another example (Example II) which has three
migration steps,
F <: E <: D
all start with m(Date, Time)
step 1: D m(Date, Time) -> D.m(LDT, Time)
step 2: E.m(Date, Time) -> E.m( Date, LDT)
step 3: D.m(LDT, Time) -> D.m(LDT, LDT)
http://cr.openjdk.java.net/~acorn/Forwarders.pdf
thanks,
Karen
> On Apr 12, 2019, at 11:44 AM, Brian Goetz <brian.go...@oracle.com> wrote:
>
>
>
>> A VM perspective:
>>
>> invocation
>> dynamic receiver
>> resolution
>> NOT invoked
>> selection:
>> actual execution
>> invokevirtual D::m(LDT)
>> D
>> D.m(LDT)
>> D.m(LDT)
>> invokevirtual D::m(LDT)
>> E
>> D.m(LDT)
>> E.m(LDT)
>> reverser: adapt LDT->Date
>> invoke local E.m(Date)
>> if return had changed, adapt return back
>> invokevirtual D::m(Date)
>> D
>> D.m(Date)
>> D.m(Date)
>> forwarder: adapt Date->LDT
>> invoke local m(LDT)
>> if return had changed, adapt
>> invokevirtual D.m(Date)
>> E
>> D.m(Date)
>> E.m(Date)
>> invokevirtual E.m(LDT)
>> E
>> E.m(LDT)
>> reverser)
>> E.m(LDT):
>> reverser: adapt LDT->Date
>> invoke local E.m(Date)
>> if return had changed, adapt return back
>> invokevirtual E.m(Date)
>> E
>> E.m(Date)
>> E.m(Date) // original - unchanged behavior
>>
>
> Let me try from the other direction, using the JVMS terminology rather than
> appealing to as-if. Where I think we're saying slightly different things is
> in the interpretation of the lines I colored in blue above (hope the
> formatting came through.) You are talking about the E.m(Date) that appears
> in E.class (good so far). But I'm talking about the _members_ of E. And the
> E.m(Date) that appears in E.class should _not_ be considered a (new-to-E)
> member of E. Instead, that E.m(Date) gives rise to a synthetic member
> E.m(LDT). I have colored two cases in red because I think this is where our
> assumptions really parted ways; will come back to this at the bottom.
>
> Here's why I'm harping on this distinction; we mark methods as "forwarders"
> and do something special when we see something override a forwarder. Taking
> the same hierarchy:
>
> // before
> class D {
> void m(Date) { }
> }
>
> class E extends D {
> void m(Date) { }
> }
>
> // middle -- D migrates, but E not yet
> class D {
> void m(LDT) { }
> @Forwarding( m(LDT) } void m(Date);
> }
>
> class E extends D {
> void m(Date) { }
> }
>
> // after -- E finally gets the memo
> class D {
> void m(LDT) { }
> @Forwarding( m(LDT) } void m(Date);
> }
>
> class E extends D {
> void m(LDT) { }
> }
>
> Now, let's draw inheritance diagrams (these are not vtables, they are member
> tables). I'll use your notation, where I think D.m(X) means "the Code
> attribute declared in D for m(X)".
>
> Before
> m(Date)
> D
> D.m(Date)
> E
> E.m(Date)
>
> This part is easy; D has m(Date), and E overrides it.
>
> Middle
> m(LDT)
> m(Date)
> D
> D.m(LDT)
> forwarder -> m(LDT)
> E
> reverser adapted from E.m(Date)
> inherits forwarder
>
> Now, both D and E have both m(Date) and m(LDT). D has a real method for
> m(LDT), and a forwarder for m(Date). E has an m(Date), which we see
> overrides a forwarder. So we adapt it to be an m(LDT), but we consider E to
> have inherited the forwarder from D. I'll come back to this in a minute.
>
> After m(LDT)
> m(Date)
> D
> D.m(LDT)
> forwarder -> m(LDT)
> E
> E.m(LDT)
> inherits forwarder
>
> In this nirvana, there is a forwarder still, but it doesn't affect E, because
> E has already gotten the memo. It sits around purely in the case that
> someone calls m(Date).
>
> OK, so why am I saying that membership has to be tilted this way? Let's go
> back to the middle case, and add
>
> class F extends E {
> void m(Date) { } // still didn't get the memo
> }
>
>
> Middle
> m(LDT)
> m(Date)
> D
> D.m(LDT)
> forwarder -> m(LDT)
> E
> reverser adapted from E.m(Date)
> inherits forwarder
> F
> reverser adapted from F.m(Date)
> inherits forwarder
>
> When we go to compute members, I want to see that _F.m(Date) overrides a
> forwarder too_. If we merely put E.m(Date) in the (E, m(Date)) box, then it
> looks like F is overriding an ordinary member, and no reverser is generated.
> (Or, we have to keep walking up the chain to see if E.m(Date) in turn
> overrides a forwarder -- yuck, plus, that makes forwarder-overrides-forwarder
> even messier.
>
> Now, back to your table. The above interpretation of what is going on comes
> to the same answer for all of the rows of your table, except these:
>
>>
>> invocation
>> dynamic receiver
>> resolution
>> NOT invoked
>> selection:
>> actual execution
>> invokevirtual D.m(Date)
>> E
>> D.m(Date)
>> E.m(Date)
>> invokevirtual E.m(Date)
>> E
>> E.m(Date)
>> E.m(Date) // original - unchanged behavior
>>
>
> You are thinking "E has a perfectly good m(Date), let's just select that".
> Makes sense, but the cost of that is that it complicates calculation of
> membership and overriding. I think I am content to let invocations of
> m(Date) on receivers of type E go through both rounds of adaptation: forward
> the call (with adaptation) to m(LDT), which, in the case of E, does the
> reverse adaptations and ends up at the original Code attribute of E.m(Date).
> This sounds ugly (and we'd need to justify some potential failures) but leads
> us to a simpler interpretation of migration.
>
> In your model, we basically have to split the box in two:
>
>
> After m(LDT)
> m(Date)
> D
> D.m(LDT)
> forwarder -> m(LDT)
> E
> E.m(LDT)
> E.m(Date), but also is viewed as a forwarder by subclasses
>
> I think its a good goal, but I was trying to eliminate that complexity by
> accepting the round-trip adaptation -- which goes away when E gets the memo.
>
>
