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.
