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.
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
- 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); }
> 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
> 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
> 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
the 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.
dy 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"
>> À: "valhalla-spec-experts&
gt; À: "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
> pressur
16 matches
Mail list logo