I agree, and I think this is already implied by the race-arbitrating
behavior of CP resolution. If two threads race to resolve the same CP#,
the VM will arbitrarily pick a winner, and toss the losing result.
Which means that both results must be, in some sense, equivalent. But
there's no harm in stating it (just as there's no harm in reminding
people that these are supposed to be CONSTANTS.)
On 8/17/2017 2:32 PM, [email protected] wrote:
----- Mail original -----
De: "Brian Goetz" <[email protected]>
À: [email protected]
Cc: "amber-spec-experts" <[email protected]>
Envoyé: Jeudi 17 Août 2017 20:07:28
Objet: Re: Condy bsm should be idempotent
So, this is more of a purity requirement -- that the result of the
bootstrap be consistently derived from its arguments and no other
state. But you are not asking for heroic interning -- just that the
bootstraps not do anything "funny". (This is in the same category as
"the result should be a constant", though neither the language nor VM
can enforce this.) Right?
yes !
Rémi
On 8/17/2017 1:50 PM, [email protected] wrote:
----- Mail original -----
De: "Brian Goetz" <[email protected]>
À: [email protected]
Cc: "amber-spec-experts" <[email protected]>
Envoyé: Jeudi 17 Août 2017 19:35:33
Objet: Re: Condy bsm should be idempotent
This is going to be problematic for bootstraps that produce, e.g.,
arrays; their equals() method delegates to Object.equals(), which means
such bootstraps would have to maintain an (expensive!) cache for interning.
fully agree,
i've forget the case of array,
structurally equivalent <=> == for primitives, Object.equals for objects and
Arrays.equals() for arrays.
It is an old problem that constant resolution can be racy, but we would
like for the JVM to manage the race, not the bootstraps.
either we specify that the BSM has to be idempotent and the VM doesn't have to
enforce that,
the other solution is to say that the semantics of condy allow the resolved
constant to be a result of a previous call of the BSM with the same arguments.
also, if we want to be able to resolve condy at jlink time, we also need the
same kind of wordings, because currently a BSM can depend on the daytime.
Rémi
On 8/17/2017 1:30 PM, [email protected] wrote:
equals,
if they are structurally equivalent, same name, same descriptor, same bsm and
same bsm arguments,
they should produce the same result.
Rémi
----- Mail original -----
De: "Brian Goetz" <[email protected]>
À: "Remi Forax" <[email protected]>, "amber-spec-experts"
<[email protected]>
Envoyé: Jeudi 17 Août 2017 19:22:21
Objet: Re: Condy bsm should be idempotent
Can you clarify what you mean by "same"? According to equals(), or ==?
On 8/17/2017 12:15 PM, Remi Forax wrote:
There is a way to solve that, mandate the the BSM of a Condy as to be
idempotent, i.e. a call to a BSM with the same arguments should provide the
same result.
