Frozen objects?

[Holo The Sage Wolf]

I think that indeed the main concern for the run time is races, but even
ignoring races, there is (almost*) no real to make the compiler know when
there is no illegal access to the values.

I do not think that introducing a language level/runtime mechanism that has
a consequences on what is a valid code without a real way enforce it is
good.

*Like Brian G. Said, final fields has a specific time in their lifecycle
where they can be modified which does allow the compiler to do it's job,
the only way (I can think of) to have a user code at an enforced lifecycle
currently is through passing scopes (/continuations/lambdas/however you
want to call them) to the said object, and have the object implement a
mechanism to run these scopes.

I'll advocate for this every time I can, I believe that we should start a
conversation about designing a way to have a better control at the
lifecycle of an object. (E.g. enhanced try-with-resources of sort)

On Tue, 19 Dec 2023, 01:56 Dan Heidinga, <dan.heidinga at oracle.com> wrote:

> Let me throw out one other concern: races.  The invariant frozen objects
> want is that the application and runtime can trust they will never be
> mutated again.  Unfortunately, if the object is published across threads
> before it is frozen, then that invariant is very difficult and expensive to
> maintain.
>
>
>
> If two threads, A & B, both have references to the object and thread A
> freezes it, B may still be publishing writes to it that A only observes
> later.  To ensure the right JMM happens-before relationship for fields of
> Freezable objects, both reads and writes would need to be more expensive
> (volatile semantics?) until a thread could validate the object it was
> operating on was frozen.
>
>
>
> Freezing is not just a free set of unexplored optimizations.  There’re
> also new costs associated with it across the runtime (field read/write,
> profiling, etc).
>
>
>
> --Dan
>
>
>
> *From: *amber-dev <amber-dev-retn at openjdk.org> on behalf of Archie Cobbs <
> archie.cobbs at gmail.com>
> *Date: *Saturday, December 16, 2023 at 12:33 PM
> *To: *amber-dev <amber-dev at openjdk.org>
> *Subject: *Frozen objects?
>
> Caveat: I'm just trying to educate myself on what's been discussed in the
> past, not actually suggest a new language feature. I'm sure this kind of
> idea has been discussed before so feel free to point me at some previous
> thread, etc.
>
>
>
> In C we have 'const' which essentially means "the memory allocated to this
> thing is immutable". The nice thing about 'const' is that it can apply to
> an individual variable or field in a structure, or it can apply to an
> entire C structure or C array. In effect it applies to any contiguous
> memory region that can be named/identified at the language level.
>
>
>
> On the other hand, it's just a language fiction, i.e., it can always be
> defeated at runtime by casting (except for static constants).
>
>
>
> In Java we have 'final' which (in part) is like 'const' for fields and
> variables, but unlike C 'final' can't be applied to larger memory regions
> like entire objects or entire arrays.
>
>
>
> In C, 'const' can be applied "dynamically" in the sense I can cast foo to
> const foo. Of course, this is only enforced at the language level.
>
>
>
> Summary of differences between C 'const' and Java 'final':
>
> ·         Granularity:
>
> o    C: Any contiguous memory region that has a language
> name/identification
>
> o    Java: At most 64 bits at a time (*) and arrays are not included
>
> o    Advantage: C
>
> ·         Enforcement:
>
> o    C: Enforced only by the compiler (mostly)
>
> o    Java: Enforced by the compiler and at runtime
>
> o    Advantage: Java
>
> ·         Dynamic Application:
>
> o    C: Yes
>
> o    Java: No
>
> o    Advantage: C
>
> (*) With records and value objects we are gradually moving towards the
> ability for larger things than an individual field to be 'const'. More
> generally, Java has slowly been glomming on some of the goodness from
> functional programming, including making it easier to declare and work with
> immutable data.
>
>
>
> This all begs the question: why not take this idea to its logical
> conclusion? And while we're at it, make the capability fully dynamic,
> instead of limiting when you can 'freeze' something construction time?
>
>
>
> In other words, add the ability to "freeze" an object or array. If 'x' is
> frozen, whatever 'x' directly references becomes no longer mutable.
>
>
>
> A rough sketch...
>
>
>
> Add new Freezable interface:
>
>
>
>     public interface Freezable {
>
>         boolean isFrozen();
>
>         static boolean freeze(Freezable obj);   // returns false if
> already frozen
>
>     }
>
>
>
> Arrays automatically implement Freezable (just like they do Cloneable)
>
>
>
> What about the memory model? Ideally it would work as if written like this:
>
>
>
>     public class Foo implements Freezable {
>
>         private volatile frozen;    // set to true by Freezable.freeze()
>
>         void mutateFooContent(Runnable mutation) {
>
>             if (this.frozen)
>
>                 throw new FrozenObjectException();
>
>             else
>
>                 mutation.run();
>
>         }
>
>     }
>
>
>
> But there could be a better trade-off of performance vs. semantics.
>
>
>
> Other trade-offs...
>
> ·         (-) All mutations to a Freezable would require a new 'frozen'
> check (* see below)
>
> ·         (-) There would have to be a new bit allocated in the object
> header
>
> ·         (+) Eliminate zillions of JDK defensive array copies (things
> like String.toCharArray())
>
> ·         (+) JIT optimizations for constant-folding, etc.
>
> ·         (+) GC optimizations
>
> o    (*) Put frozen objects into a read-only region of memory to
> eliminate mutation checks
>
> o    Optimize scanning of frozen references (since they never change)
>
> I'm curious how other people think this idea would or wouldn't make sense
> for Java & what's been decided in the past.
>
>
>
> Thanks,
>
> -Archie
>
>
>
> --
>
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231219/63d7c348/attachment-0001.htm>