Condy bsm should be idempotent

[Maurizio Cimadamore]

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).

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.