Draft JEP Announcement: "Computed Constants"

[John Rose]

On 28 Jul 2023, at 9:28, Maurizio Cimadamore wrote:

> On 28/07/2023 17:25, Maurizio Cimadamore wrote:
>>
>> On 28/07/2023 17:21, Brian Goetz wrote:
>>> (a MH overload factory is entirely reasonable.)
>>
>> This was also what I was tinkering with when thinking about Dan's question.
>
> Hit send too fast. There's other avenues to explore to. For instance, lambdas that have same signature and captured state might be able to share the same class (e.g. by accepting a MH as construction parameter and stashing it in a private "trusted" final field). This should deliver footprint savings not just for computed constants, but for all lambda-heavy APIs (e.g. classfile API, streams). That said, pulling that off, and in a way that doesn't break C2 optimizations might be hard (I'd suspect that each lambda having its distinct nominal class gives C2 a lot of room to speculate).

Maybe, but (as you suspect) C2 likes distinct lambdas, if they are going to be invoked many times.

The lambdas for CCs are by definition invoked only once, so they should be optimized more for space than for speed.  That’s why I suggest rolling all the initializers in a single class (or as single package???) into one big method with a string-switch.  That big guy doesn’t optimize well, but nobody will ever care, and he takes up the least possible space.  Just like <clinit>.  In fact, that’s how you get parity with <clinit>, defining $fieldinit$ as an alternative, better organized container for initializers.