Condy bsm should be idempotent

[Brian Goetz]

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, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "Brian Goetz" <brian.goetz at oracle.com>
>> À: forax at univ-mlv.fr
>> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>> 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, forax at univ-mlv.fr wrote:
>>> ----- Mail original -----
>>>> De: "Brian Goetz" <brian.goetz at oracle.com>
>>>> À: forax at univ-mlv.fr
>>>> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>>>> 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, forax at univ-mlv.fr 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" <brian.goetz at oracle.com>
>>>>>> À: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts"
>>>>>> <amber-spec-experts at openjdk.java.net>
>>>>>> 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.