Condy bsm should be idempotent

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> À: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 17 Août 2017 19:01:32
> Objet: Re: Condy bsm should be idempotent

>> On 17 Aug 2017, at 09:30, Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>> wrote:
>> 
>> Well spotted - this would be an issue for my bytecode API too (currently my API
>> is assuming that if two condy CP entries are the same, only one entry has to be
>> written in the resulting classfile stream).
>> 
> 
> What is wrong with that?
> 
> If there are two separate condy CP entries with the same name, type and BSM
> index then resolution of those two condy CP entries should produce the same
> value. So so two such entries are redundant and it’s beneficial to only produce
> one entry.

Nothing wrong, that's the point !
it's just that the current spec does not allow to produce only one entry,
according to the current spec, two calls of the same bsm with the same arguments may produce different results, 
that's why I propose to change the spec by adding that the bsm has to be idempotent.

> 
> Paul.

Rémi

> 
>> Maurizio
>> 
>> 
>> On 17/08/17 17:15, Remi Forax wrote:
>>> Hi all,
>>> have some of you may know, i've started to implement ConstantDynamic in ASM,
>>> and the spec currently breaks an invariant of ASM that i would like to keep.
>>> 
>>> ASM API do not expose the constant of the constant pool,
>>> it provides methods that decode/encode instructions that as a side effect decode
>>> constant pool constants on demand and share them when automatically when
>>> encoding, so there is no need to have an API that directly expose the constant
>>> pool constants.
>>> 
>>> The problem is that Condy breaks that, because the VM calls the bsm of a condy
>>> constant only once* by constant pool entry.
>>> So there is a difference from the user point of view of a constant pool
>>> containing two Condy resolving the same BSM with the same arguments and one
>>> Condy refencing the same BSM with the same arguments,
>>> in the former, the BSM will be called twice while in the later case, the BSM
>>> will be called once.
>>> 
>>> 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.
>>> 
>>> If someone does not want to share several Condy, it can specify different names
>>> for each of them, respecting the idempotent criteria.
>>> 
>>> I've mostly implemented the current semantics in ASM but the result is ugly, i
>>> had to specialize the resolution/caching for Condy, i'm not able to reuse the
>>> code that deals with invokedynamic. And from the API point of view, it's
>>> awkward because it works automatically for all constants but Condy, for which
>>> the user have to take extra care.
>>> 
>>> Rémi
>>> 
>>> * let say threads do not exist.