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.
I
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
This leads us to the next question, given that you can only override "locally"
a forwarder, what if a forwarder overrides a forwarder ? You throw a LinkageError ?
Yes, this could arise from inconsistent separate compilation (I thought
I covered this in my doc?) Best choice is probably to l
- Mail original -
> De: "Brian Goetz"
> À: "Karen Kinnear"
> Cc: "valhalla-spec-experts"
> Envoyé: Vendredi 12 Avril 2019 01:04:15
> Objet: Re: Updated VM-bridges document
> On 4/11/2019 5:18 PM, Karen Kinnear wrote:
>>>
>&
On 4/11/2019 5:18 PM, Karen Kinnear wrote:
OK, so at this point, the classfiles that have been loaded look like:
class D {
void m(LDT) { real method }
@Forwarding(m(LDT)) abstract void m(Date);
}
class E extends D {
@Override
m(Date) { impl }
> On Apr 10, 2019, at 5:22 PM, Brian Goetz wrote:
>
> OK, so in the old world, D has m(Date).
>
>
> Now, D has m(LDT), with a forwarder from m(Date) -> m(LDT), with some sort of
> metadata stapled somewhere to effect the Date <--> LDT conversions.
>
>> class E extends D { m(Date); } whi
> De: "Brian Goetz"
> À: "valhalla-spec-experts"
> Envoyé: Jeudi 11 Avril 2019 21:52:23
> Objet: Re: Updated VM-bridges document
> This was received through a side channel:
>> From: [ mailto:sebastian.sickelm...@gmx.de | sebastian.sickelm...@gmx.de ]
&g
This was received through a side channel:
From: sebastian.sickelm...@gmx.de
Subject: Re: Updated VM-bridges document
Hi,
i have a question regarding the discussed forwarding schema for fields.
Should it be possible to forward field access to methods, so that
we can safely remove public fields
OK, so in the old world, D has m(Date).
Migration step 1: author: Date -> LocalDateTime
old class D { m(Date); }
Migration step 2: change method declarer: new class D {m(LDT);}
and javac creates a forwarder m(Date); -> Date->LDT/m(LDT);
Now, D has m(LDT), with a forwarder from m(Da
Brian,
Here is an example of when I believe we need to create a reverser - let me know
if my
assumptions don’t match yours.
Migration step 1: author: Date -> LocalDateTime
old class D { m(Date); }
Migration step 2: change method declarer: new class D {m(LDT);}
and javac creates a for
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Mardi 9 Avril 2019 15:39:19
> Objet: Re: Updated VM-bridges document
>>> OK, I see what you’re getting at now. Yes, this is one of the implementation
>>&g
> OK, I see what you’re getting at now. Yes, this is one of the implementation
> possibilities. I was mostly looking to validate the concepts before diving
> into the representational details. One key point is that the default case
> should be able to proceed with no bootstrap; a small set of
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 8 Avril 2019 20:39:03
> Objet: Re: Updated VM-bridges document
> OK, I see what you’re getting at now. Yes, this is one of the implementation
> possibili
result when overridden by legacy
subclasses.
> On Apr 8, 2019, at 1:18 PM, fo...@univ-mlv.fr wrote:
>
>
>
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 8 Avril 2019 16:24:21
> Objet: Re: Updated VM
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 8 Avril 2019 16:24:21
> Objet: Re: Updated VM-bridges document
>> The other thing is that Forwarding bridge should not use an adapter but a
>> bootst
>
> The other thing is that Forwarding bridge should not use an adapter but a
> bootstrap method.
Can you explain exactly what you mean here? Because in my mind, the adapter
_is_ a bootstrap method — it is code to which the VM upcalls at preparation /
link time to help establish linkage.
S
ohn has already proposed that we should support a bootstrap method
> that returns a MethodHandle instead of a CallSite, this is exactly what we
> need here.
>
> regards,
> Rémi
>
> - Mail original -----
>> De: "Brian Goetz"
>> À: "valhall
Goetz"
> À: "valhalla-spec-experts"
> Envoyé: Jeudi 4 Avril 2019 14:33:39
> Objet: Updated VM-bridges document
> At the BUR meeting, we discussed reshuffling the dependency graph to do
> forwarding+reversing bridges earlier, which has the effect of taking some
At the BUR meeting, we discussed reshuffling the dependency graph to do
forwarding+reversing bridges earlier, which has the effect of taking some
pressure off of the descriptor language. Here’s an updated doc on
forwarding-reversing bridges in the VM.
I’ve dropped, for the time being, any di
19 matches
Mail list logo