Condy bsm should be idempotent
paul.sandoz at oracle.com
Thu Aug 17 17:01:32 UTC 2017
> 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.
> 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.
>> * let say threads do not exist.
More information about the amber-spec-experts