On Wed, 9 Nov 2022 00:10:48 GMT, Vladimir Ivanov <vliva...@openjdk.org> wrote:
>> Volodymyr Paprotski has updated the pull request incrementally with one >> additional commit since the last revision: >> >> fix 32-bit build > > src/hotspot/share/opto/library_call.cpp line 7014: > >> 7012: const TypeKlassPtr* rklass = >> TypeKlassPtr::make(instklass_ImmutableElement); >> 7013: const TypeOopPtr* rtype = >> rklass->as_instance_type()->cast_to_ptr_type(TypePtr::NotNull); >> 7014: Node* rObj = new CheckCastPPNode(control(), rFace, rtype); > > FTR it's an unsafe cast since it doesn't involve a runtime check from > `IntegerModuloP` to `ImmutableElement`. Please, lift as much checks into Java > wrapper as possible. Ah, yeah.. I quite suspected I didn't emulate all the bytecodes needed. Thanks for the info. So this is a bit of a quandary.. I had done the intrinsic more in Java before, but it slows down the non-intrinsic path (This was the discussion we were having with Jamil). In Java, the limbs are not 'accessible' per-se.. They are in a separate package hidden behind and interface.. and in a nested non-static class inside an abstract class... Its quite well designed. Its just makes what I want to do break most encapsulations. There is a method (`asByteArray`) to extract the limbs that I was previously using, but that slows down non-intrinsic path (to be honest it slows down the intrinsic path too, but the assembler makes some of that back.. You can see that from the numbers I posted for Jamil, vs original in the PR header; originally I got 18x, and now with accessing limbs directly its 19x). If I had some way to check 'is intrinsic available', I could at least not slow down the current code. I would still have to break the encapsulation to do the checks/casts though. It all seems less-then-perfect. ------------- PR: https://git.openjdk.org/jdk/pull/10582
