RFR: 8330465: Stable Values and Collections (Internal) [v16]
Olexandr Rotan
rotanolexandr842 at gmail.com
Thu May 16 15:28:02 UTC 2024
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).
On Thu, May 16, 2024 at 5:07 PM Per Minborg <pminborg at openjdk.org> wrote:
> On Thu, 16 May 2024 12:48:24 GMT, Per Minborg <pminborg at openjdk.org>
> wrote:
>
> >> # Stable Values & Collections (Internal)
> >>
> >> ## Summary
> >> 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.
> >>
> >> ## Goals
> >> * Provide an easy and intuitive API to describe value holders that can
> change at most once.
> >> * Decouple declaration from initialization without significant
> footprint or performance penalties.
> >> * Reduce the amount of static initializer and/or field initialization
> code.
> >> * Uphold integrity and consistency, even in a multi-threaded
> environment.
> >>
> >> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> >>
> >> ## Performance
> >> Performance compared to instance variables using two `AtomicReference`
> and two protected by double-checked locking under concurrent access by all
> threads:
> >>
> >>
> >> Benchmark Mode Cnt Score
> Error Units
> >> StableBenchmark.atomic thrpt 10 259.478 ?
> 36.809 ops/us
> >> StableBenchmark.dcl thrpt 10 225.710 ?
> 26.638 ops/us
> >> StableBenchmark.stable thrpt 10 4382.478 ?
> 1151.472 ops/us <- StableValue significantly faster
> >>
> >>
> >> Performance compared to static variables protected by
> `AtomicReference`, class-holder idiom holder, and double-checked locking
> (all threads):
> >>
> >>
> >> Benchmark Mode Cnt Score
> Error Units
> >> StableStaticBenchmark.atomic thrpt 10 6487.835 ?
> 385.639 ops/us
> >> StableStaticBenchmark.dcl thrpt 10 6605.239 ?
> 210.610 ops/us
> >> StableStaticBenchmark.stable thrpt 10 14338.239 ?
> 1426.874 ops/us
> >> StableStaticBenchmark.staticCHI thrpt 10 13780.341 ?
> 1839.651 ops/us
> >>
> >>
> >> 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):
> >>
> >>
> >> Benchmark Mode Cnt Score
> Error Units
> >> StableListElementBenchmark.instanceArrayList thrpt 10 5812.992 ?
> 1169.730 ops/us
> >> StableListElementBenchmark.instanceList thrpt 10 4818.643 ?
> 704.893 ops/us
> >> StableListElementBenchmark...
> >
> > Per Minborg has updated the pull request incrementally with one
> additional commit since the last revision:
> >
> > Fix copyringht issues
>
> Here are some updated benchmark graphs where we sum two instance variables
> of different sorts (higher is better):
>
> 
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2115343828
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240516/7fa869a5/attachment-0001.htm>
More information about the compiler-dev
mailing list