How to implement a record de-constructor ?
Daniel_Heidinga at ca.ibm.com
Tue Mar 20 20:31:00 UTC 2018
>>> 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
>>> that just a performance issue) then the VM will remove unused
>>> 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
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
>> are likely to be allocating and copying stuff; even if the results
>> unused, there are still many reasons why the JIT might not elide
>> 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
More information about the amber-spec-observers