[records] Ancillary fields

[Kevin Bourrillion]

On Wed, Apr 18, 2018 at 1:39 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Ahh, you missed the `lazy` keyword on there :-) Which is good because it
> raises an issue: when you forget it, bad performance may result without
> other observable consequence. Although, it's already the case that reading
> code like the above ought to raise all kinds of alarm bells (e.g., now I
> want to go check which fields computeHashCode() might be referring to, and
> where *they're* initialized), so I *should* be looking for that `lazy`
> keyword to put my mind at ease. So maybe this is okay.
>
>
> Well, "bad" is relative; it won't be any worse than what you do today with
> eager static fields.
>

Yes, it's just that lazy and eager code aren't as trivially distinguishable
anymore, so... I thought I should mention it, but it's no kind of
dealbreaker.



> For instance fields, we have a choice; use extra space in the object to
> store the "already initialized" bit, or satisfy ourselves with the trick
> that String does with hashCode() -- allow redundant recomputation in the
> case where the initializer serves up the default value.
>

I strongly suspect there isn't going to be any generally safe way to do the
latter.


So I think the divide is not ref-vs-primitive but whether we are willing to
> take the recomputation hit when it serves up a default value.
>
>
>


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180418/11f11b1e/attachment.html>