Access to BCI for Unbound and Bound instructions

[Gary Frost]

First thanks for this API.  I am  switching to it from a proprietary library I wrote a long time ago, I really like it.  But have a question about Unbound vs Bound instructions.


I am interested in the rationale behind Bound and Unbound Instructions.  It seems to be related to whether they are somehow ‘tethered’ to a BCI/Pos? or indeed even to a specific CodeModel or var slot.  Is that correct? Or is there some other reason for separating the instructions this way?


In my use case I am interested in the relative order of instructions and therefore need the BCI for all instructions. For Bound instructions I can extract the pos (which can be easily mapped to BCI). For Unbound I cannot easily determine the BCI.


Undeterred 😉 my first hack was to just create a side mappings Map< Instruction, Integer> as I walk through the elements. So....


codeModel.elements().forEach((codeElement -> {

  /* Build side mappings here */

});


Sadly  the lack of guaranteed 'identity' from

    CodeImpl.bcToInstruction(int bc, int pos)

caught me off-guard :)

It turns out that some instructions are indeed allocated


return switch (bc) {

    case BIPUSH -> new BoundArgumentConstantInstruction(... pos);


whereas others (those pesky Unbound ones)  are pulled from a cache of pre-allocated  instructions


default -> {

     InstructionData.singletonInstructions[bc];



rendering my Map<Instruction, Integer> somewhat useless ;)

I doubt if my 'need' for accessing the BCI of each instruction is unique, so I am wondering whether the value of this Unbound/Bound separation might be worth it in the long run.


Or at least whether a CodeModel.getBCI(Instruction) helper method could be introduced, which has tricks to step around this 'identity' issue.

Gary


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230209/9502d98d/attachment-0001.htm>