>> >>> if a de-constructor is inlined by the VM the same way getter is >inlined by the >>> VM, i.e. most of the time, >>> and if the de-constructor has no side effect (otherwise you have >bigger problem >>> that just a performance issue) then the VM will remove unused >computation, >>> share common sub-expressions, etc.
Even ignoring side-effects, the cost model for a getter method is vastly different than invoking a MethodHandle from a List / array of MethodHandles, even if that List/array is rooted in the constant pool. The getter is an invokevirtual of cp data that the VM *knows* can't change. The MH is fetched from a mutable object (at least as far as the VM can trust) and then invoked. There's a lot of simulation overhead there - think emulating C++ vtables in C. >> >> I would love to buy this, but I don't. The expensive actions of >dtors >> are likely to be allocating and copying stuff; even if the results >are >> unused, there are still many reasons why the JIT might not elide >the >> allocation and copying. > >Apart if people still write side effects in their constructor in >2018, it should not be an issue, >we are still missing frozen arrays but immutable collections >(List.of+List.copyOf) is a good enough replacement. A frozen array would help as the VM could be taught the elements won't change. A List, even an immutable one, looks mutable to the VM. --Dan
