----- Mail original ----- > De: "Paul Sandoz" <[email protected]> > À: "Maurizio Cimadamore" <[email protected]> > Cc: "Remi Forax" <[email protected]>, "amber-spec-experts" > <[email protected]> > 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 >> <[email protected]> >> 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.
