On Wed, Apr 27, 2022 at 9:36 PM Kevin Bourrillion wrote:
(Type R) e.g. Rational, EmployeeId: the default value is illegal; can't
> even construct it on purpose. Every method on it *should* call
> `checkValid()` first. Might as well repurpose it as a pseudo-null. Bugs
> could be prevented by some
This is kinda reading as...
* First we have 3 buckets
* But people ask if there could be just 2 buckets
* No, so let's have 5 buckets.
I don't understand why this is happening, but I take it back! I take back
what I said about 2 buckets!
I'm not sure what problem this is needed to solve.
~~
By
(somehow two versions of this got sent, along with some cut and paste from
another thread; please disregard whatever looks weird.)
> On Apr 27, 2022, at 5:50 PM, Brian Goetz wrote:
>
> Let me try and put some more color on the bike shed (but, again, let’s focus
> on model, not syntax, for now
Let me try and put some more color on the bike shed (but, again, let’s focus on
model, not syntax, for now.)
We have two axes of variation we want to express with non-identity classes:
atomicity constraints, and whether there is an additional zero-default
companion type. These can be mostly or
We can divide the VM flattening strategy into three rough categories (would you
like some milk with your eclair?):
- non-flat — use a pointer
- full-flat — inline the layout into the enclosing container, access with
narrow loads
- low-flat — use some combination of atomic operations to cram m
Let me try and put some more color on the bike shed (but, again, let’s focus on
model, not syntax, for now.)
We have two axes of variation we want to express with non-identity classes:
atomicity constraints, and whether there is an additional zero-default
companion type. These can be mostly or
Please see these two spec change documents for JLS and JVMS changes in support
of the Value Objects feature.
http://cr.openjdk.java.net/~dlsmith/jep8277163/jep8277163-20220427/specs/value-objects-jls.html
http://cr.openjdk.java.net/~dlsmith/jep8277163/jep8277163-20220427/specs/value-objects
- Original Message -
> From: "Dan Heidinga"
> To: "Brian Goetz"
> Cc: "valhalla-spec-experts"
> Sent: Wednesday, April 27, 2022 8:51:15 PM
> Subject: Re: User model stacking
> I'm trying to understand how this refactoring fits the VM physics.
>
> In particular, __non-atomic & __zero-ok
I'm trying to understand how this refactoring fits the VM physics.
In particular, __non-atomic & __zero-ok fit together at the VM level
because the VM's natural state for non-atomic (flattened) data is zero
filled. When those two items are decoupled, I'm unclear on what the
VM would offer in that
This is circling around the same root issues as the "Foo / Foo.ref
backward default" thread - which is really when should a developer
pick a B3 over a B2.
Kevin's thought experiment in that thread seems to be approaching this
same idea from a different angle:
> (Thought experiment: if we had an an
- Original Message -
> From: "Brian Goetz"
> To: "valhalla-spec-experts"
> Sent: Wednesday, April 27, 2022 6:44:01 PM
> Subject: User model stacking
> Here’s some considerations for stacking the user model. (Again, please let’s
> resist the temptation to jump to the answer and then defe
Writing immutable objects in Java is hard, there is already a check list:
- be sure that your class in not only unmodifiable but really immutable,
storing a mutable class in a field is an issue
- do you have declared all fields final, otherwise you have a publication
issue
- your construct
Here’s some considerations for stacking the user model. (Again, please let’s
resist the temptation to jump to the answer and then defend it.)
We have a stacking today which says:
- B1 is ordinary identity classes, giving rise to a single reference type
- B2 are identity-free classes, giving
> From: "Brian Goetz"
> To: "valhalla-spec-experts"
> Sent: Wednesday, April 27, 2022 3:59:31 PM
> Subject: On tearing
> Several people have asked why I am so paranoid about tearing. This mail is
> about
> tearing; there’ll be another about user model stacking and performance models.
> (Please,
On Wed, Apr 27, 2022 at 11:03 AM Dan Smith wrote:
> On Apr 26, 2022, at 5:22 PM, Kevin Bourrillion wrote:
>
> (Thought experiment: if we had an annotation meaning "using the .val type
> is not a great idea for this class and you should get a compile-time
> warning if you do" would we really
On Apr 26, 2022, at 5:22 PM, Kevin Bourrillion
mailto:kev...@google.com>> wrote:
(Thought experiment: if we had an annotation meaning "using the .val type is
not a great idea for this class and you should get a compile-time warning if
you do" would we really and I mean *really* even need b
Several people have asked why I am so paranoid about tearing. This mail is
about tearing; there’ll be another about user model stacking and performance
models. (Please, let’s try to resist the temptation to jump to “the answer”.)
Many people are tempted to say “let it tear.” The argument for
17 matches
Mail list logo
