<div dir="ltr">Is it possible to make stable values and collections Serializable? I see various applications for this feature in entity classes as a way to preserve immutability of entity fields and at the same time not break current JPA specifications. It is a *very* common task in commercial development. Current workarounds lack either thread safety or performance, and this looks like a really good solution for both of those problems. However, unless StableValue is serializable, it is really unlikely that JPA will adopt them (we have precedent with Optional).<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 16, 2024 at 5:07 PM Per Minborg <<a href="mailto:pminborg@openjdk.org">pminborg@openjdk.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 16 May 2024 12:48:24 GMT, Per Minborg <<a href="mailto:pminborg@openjdk.org" target="_blank">pminborg@openjdk.org</a>> wrote:<br>
<br>
>> # Stable Values & Collections (Internal)<br>
>> <br>
>> ## Summary<br>
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.<br>
>> <br>
>> ## Goals<br>
>> * Provide an easy and intuitive API to describe value holders that can change at most once.<br>
>> * Decouple declaration from initialization without significant footprint or performance penalties.<br>
>> * Reduce the amount of static initializer and/or field initialization code.<br>
>> * Uphold integrity and consistency, even in a multi-threaded environment.<br>
>> <br>
>> For more details, see the draft JEP: <a href="https://openjdk.org/jeps/8312611" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8312611</a><br>
>> <br>
>> ## Performance <br>
>> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:<br>
>> <br>
>> <br>
>> Benchmark Mode Cnt Score Error Units<br>
>> StableBenchmark.atomic thrpt 10 259.478 ? 36.809 ops/us<br>
>> StableBenchmark.dcl thrpt 10 225.710 ? 26.638 ops/us<br>
>> StableBenchmark.stable thrpt 10 4382.478 ? 1151.472 ops/us <- StableValue significantly faster<br>
>> <br>
>> <br>
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):<br>
>> <br>
>> <br>
>> Benchmark Mode Cnt Score Error Units<br>
>> StableStaticBenchmark.atomic thrpt 10 6487.835 ? 385.639 ops/us<br>
>> StableStaticBenchmark.dcl thrpt 10 6605.239 ? 210.610 ops/us<br>
>> StableStaticBenchmark.stable thrpt 10 14338.239 ? 1426.874 ops/us<br>
>> StableStaticBenchmark.staticCHI thrpt 10 13780.341 ? 1839.651 ops/us<br>
>> <br>
>> <br>
>> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):<br>
>> <br>
>> <br>
>> Benchmark Mode Cnt Score Error Units<br>
>> StableListElementBenchmark.instanceArrayList thrpt 10 5812.992 ? 1169.730 ops/us<br>
>> StableListElementBenchmark.instanceList thrpt 10 4818.643 ? 704.893 ops/us<br>
>> StableListElementBenchmark...<br>
><br>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:<br>
> <br>
> Fix copyringht issues<br>
<br>
Here are some updated benchmark graphs where we sum two instance variables of different sorts (higher is better):<br>
<br>
![image](<a href="https://github.com/openjdk/jdk/assets/7457876/d82561d6-e803-4345-b6d2-6b0402e60211" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/assets/7457876/d82561d6-e803-4345-b6d2-6b0402e60211</a>)<br>
<br>
-------------<br>
<br>
PR Comment: <a href="https://git.openjdk.org/jdk/pull/18794#issuecomment-2115343828" rel="noreferrer" target="_blank">https://git.openjdk.org/jdk/pull/18794#issuecomment-2115343828</a><br>
</blockquote></div>