How to implement a record de-constructor ?

Daniel Heidinga Daniel_Heidinga at
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
>bigger problem
>>> 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 
the VM.


More information about the amber-spec-experts mailing list