How to implement a record de-constructor ?

[Daniel Heidinga]

>> 
>>> 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