On Tue, Jun 14, 2022 at 11:29 AM Dan Heidinga wrote:
>
> On Tue, Jun 14, 2022 at 10:19 AM Brian Goetz wrote:
> >
> > It took me a while to understand your concern, but I think I have it now
> > -- it is that we're effectively doing separate access control on LFoo
&
On Tue, Jun 14, 2022 at 10:19 AM Brian Goetz wrote:
>
> It took me a while to understand your concern, but I think I have it now
> -- it is that we're effectively doing separate access control on LFoo
> and QFoo. At the language level this is no problem, but the VM needs a
> story here. Is this
Overall, I like this proposal. It gives us one new "thing" value
classes, and then some additional rules on exposing the zero (or not)
and right defaults for atomic-ness.
One concern, sketched out below, about using the nest for
accessibility during class loading. Mostly an area where we'll need
On Tue, Jun 14, 2022 at 9:17 AM Brian Goetz wrote:
>
>
> The val type for B2 should not exist at all
>
>
>
> So B2 is really a B3a whose value projection is encapsulated.
>
>
> and here you lost me, .ref and .val are supposed to be projection types not
> classes, at runtime there is only one clas
On Thu, May 26, 2022 at 1:34 PM Kevin Bourrillion wrote:
>
> I'd like to bump this thread, as it seems to me to be the biggest obstacle to
> bucket 2 being able to deliver value.
>
> * A warning not just on synchronization, but on *any* identity-dependence.
This will have high costs in the regul
Thanks for writing this up. I've been thinking and playing with
related ideas and this gives a clear starting point for us to work
off.
On Thu, May 5, 2022 at 3:21 PM Brian Goetz wrote:
> There are lots of other things to discuss here, including a discussion of
> what does non-atomic B2 really
On Thu, Apr 28, 2022 at 10:13 AM Brian Goetz wrote:
>
> I threw a lot of ideas out there, and people have reacted to various corners
> of them. That’s fair; it’s a lot to take in at once. Let me focus on what I
> think the most important bit of what I wrote is, which is, where we get
> permis
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
Where is a B3 (.val) instance preferable to a B2 (B3 .ref) instance?
What are the criteria that would make an API designer expose a B3
(.val) instance in their method descriptors?
The primary benefit of a B3 (.val) instance over a B2 instance is
memory density. This relates to the containers hold
On Mon, Apr 25, 2022 at 1:59 PM Kevin Bourrillion wrote:
>
> On Mon, Apr 25, 2022 at 1:19 PM Brian Goetz wrote:
>>
>> Changing from a B2 -> B3 changes the default spelling from "L" -> "Q".
>> Why does this have to be done atomically?
>
> (First note that I'm thinking in terms of source compatibil
On Mon, Apr 25, 2022 at 1:19 PM Brian Goetz wrote:
>
> My understanding was we were going to guide most users towards B2
> values and would treat B3 as the rare, "expert" mode, for when density
> really matters. Does that decrease the education problem?
>
>
> I am not convinced it does, but am op
> In the future world, which of these declarations do we expect to see?
>
> public final class Integer { … }
>
> or
>
> public mumble value class int { … }
>
> The tension is apparent here too; I think most Java developers would hope
> that, were we writing the world from scratch, that we’
Hi Kevin,
A question about the "Values" subsection of the "Model" section. You
draw a distinction between the Platonic value and values as ephemeral
pieces of information.
> A value is less than all that! It's just an ephemeral piece of information
> being communicated directly from some progra
> Let's step back and ask "what is the purpose of
> Class::isIdentityClass". It kind of got conflated with the dynamic
> check of "does this object have identity", but really, this should be a
> query about how the class is declared -- identity class, value class, or
> identity-agnostic class. Th
On Fri, Apr 1, 2022 at 9:29 AM Brian Goetz wrote:
>
>
> > assert new Object().hasIdentity();
> > assert !new Point().hasIdentity();
> >
> > But the 'hasIdentity' method can contain arbitrary logic, and doesn't
> > necessarily need to correlate with 'getClass().isIdentityClass()'.
>
> More precise
(Sorry Dan, you're receiving this twice. I accidentally sent it off list first)
> Here's another more stable encoding, though, that feels less fiddly to me
> than what I originally wrote:
>
> ACC_VALUE means "allows value object instances"
>
> ACC_IDENTITY means "allows identity object instances
> As Dan points out, the main thing we give up by backing off from these
> interfaces is the static typing; we don't get to use `IdentityObject` as a
> parameter type, return type, or type bound. And the only reason we've come
> up with so far to want that is a pretty lame one -- locking.
Duri
A couple of comments on the encoding and questions related to descriptors.
>
> JVM proposal:
>
> - Same conceptual framework.
>
> - Classes can be ACC_VALUE, ACC_IDENTITY, or neither.
>
> - Legacy-version classes are implicitly ACC_IDENTITY. Legacy interfaces are
> not. Optionally, modern-version
>
> My initial reaction was that, no, we really do want IdentityObject here,
> because it's useful to be able to assign an abstract class type to
> IdentityObject.
>
> But: for new classes, the compiler will have an opportunity to be explicit.
> It's mostly a question of how we handle legacy cla
On Wed, Feb 23, 2022 at 1:36 PM Dan Smith wrote:
>
> Fred suggested that we enumerate the whole space here. So, some cases to
> consider:
>
> { ACC_PERMITS_VALUE, not }
> { has an declaration, not }
> { implements IdentityObject, not }
> { implements ValueObject, not }
>
> "implements" here refe
Repeating what I said in the EG meeting:
* "new" carries the mental model of allocating space. For identity
objects, that's on the heap. For values, that may just be stack space
/ registers. But it indicates that some kind of allocation / demand
for new storage has occurred.
* It's important t
> "SoV-3: constructor questions": Dan asked about validation for and
> methods. Answer: JVM doesn't care about methods in abstract
> classes, the rules about methods still uncertain.
>
> On the question of JVM validation of methods, I’m in favor of as few
> rules as possible, ideally treati
> * For WeakHashMap use cases, I would expect that any attempts to actually
> design something "good" that does what users really "want" would end up at
> some different library entirely. This is something that Caffeine probably
> does well (disclosure, I worked on the thing that became that).
>
rs to know if they need to do something to
prepare for this.
--Dan
[1] http://openjdk.java.net/jeps/390
On Thu, Jan 20, 2022 at 1:54 PM Dan Heidinga wrote:
>
> >
> > It certainly seems that all the choices are bad.
> >
> > The "obvious" choice is to simply
I've spent a good chunk of my day trying to work out whether the
behaviour described below is problematic or expected consequences of
interface (heap?) pollution.
My conclusion is that it's expected behaviour due to the way
interfaces are handled by the verifier and may, in limited places, be
prob
> > I don't understand the point of this restriction. Since
> > Ljava/lang/Object; is acceptable (and has to be), I can use a ``
> > method to return *any* class but the caller will need to downcast to
> > use it.
>
> I think the reason we might have some sort of restriction is if we intend for
>
>
> The reason John gave for allowing a method to return a super type is
> for lambda proxies.
>
> A lambda proxies is a hidden value class, i.e. a value class loaded by
> lookup.defineHiddenClass(),
> given that a hidden class as no real name, the idea is to use Object or
> perhaps the functio
be a convenient place to put
> stuff, not a mandatory feature of instance creation.
>
I think we agree here - the useful restrictions are on only allowing
aconst_init / withfield with a Nest. Given we've already agreed to
that restriction, I'm trying to understand the benefits of
After re-reading the State of Valhalla part 3 again [1], I have a
couple of questions on constructor handling:
1) The rules for handling ACC_PERMITS_VALUE are different between
SoV-2 and SoV-3 in that the language imposes constraints the VM
doesn't check. Is this deliberate?
SoV-2 says:
> The cl
> Can you mix and match both modes in the same method?
> Probably, since the interpreter doesn’t care about
> multi-bytecode patterns. Dunno if this causes a testing
> problem, and if so how to fix it. I think it’s probably
> OK, especially if we require the two-way checkcast
> (Q-Foo not a subtype
>
> It certainly seems that all the choices are bad.
>
> The "obvious" choice is to simply say that WeakReference makes no
> sense, in that it sidesteps the hard semantics questions.
It's an uncomfortable answer but it seems to provide the most
defensible (and thus understandable) semantics for u
In the Dec 2021 update to State of Valhalla, part 2: The language
model, the section on "Identity-sensitive operations" states this
about weak references:
> Weak references to value objects that contain no references to identity
> objects should never be
> cleared; weak references to value object
> Let's do an ASM thought experiment.
>
> The descriptors live in (a) {method,field}_info metadata, and (b)
> C_{Field,Method}Ref constants referred to by invoke/field access instructions.
>
> The stars, though, live somewhere completely different: the Preload
> attribute, which is not on the ins
> Which makes me ask ... if it really is a side channel, does it really go
> *in* the ClassDesc?
If it's not in the ClassDesc, then how do we communicate the side
channel to users - e.g. class file generators?
I recently rewatched your JVMLS talk from 2018 [1] where javac
converted the jl.constan
>
> This reminds me of an earlier version of the jl.constant API, where we tried
> to track the varargs bit. In the end, we dropped this, because it washed off
> too easily in the API. We could have a preload() bit that travels with the
> ClassDesc, which would then have to be propagated into
The updated api looks pretty good for handling both L and Q descriptors.
There's one case that isn't handled here though - L* descriptors.
WIth the bucket 2 & 3 design, we really have 3 kinds of descriptors:
L, Q, and L*. Over the years, we've spent a lot of time as an EG
talking about stars on d
On Thu, Dec 2, 2021 at 10:05 AM Dan Smith wrote:
>
> On Dec 2, 2021, at 7:08 AM, Dan Heidinga wrote:
>
> When converting back from our internal form to a classfile for the
> JVMTI RetransformClasses agents, I need to either filter the interface
> out if we injected it or not
Replying to both this and the previous email in one:
> I guess I prefer C and D over A and B because of the reflection magic problem,
> and also because of Dan H’s issue (IIUC) about “where do we look for the
> metadata, if not in somebody’s constant pool?”
+1 I prefer C or D as well for similar
Splitting a new thread off from Dan's email about the jep draft to
talk about the `aconst_init` bytecode:
> aconst_init, with a CONSTANT_Class operand, produces an instance of the named
> value class, with all fields set to their default values. This operation
> always has private access: a link
>
> Here's a new JEP draft that incorporates this terminology and sets us up to
> deliver Bucket 2 classes, potentially as a separate feature from Bucket 3:
>
> https://bugs.openjdk.java.net/browse/JDK-8277163
>
> Much of JEP 401 ends up here; a revised JEP 401 would just talk about
> primitive c
> This is the second turn of the crank (the first was "you can extend Object
> only"), but as this conversation hinted, there may be a further turn where
> abstract identity-agnostic classes can contribute to the layout and
> initialization of a concrete final by-value class without pulling it i
I'll echo Brian's comment that I'd like to understand Kevin's use
cases better to see if there's something we're missing in the design /
a major use case that isn't being addressed that will cause useer
confusion / pain.
That said
> Yes. The key thing is that the abstract class in question
rd for users to keep straight and
would be easy to violate when refactoring as the authors of A & B
would need to know that their subclasses include value types. And
this would be incredibly hard to keep straight across maintenance
boundaries.
--Dan
>
>
> On Nov 18, 2021, at 5:58
>> > For the moment I think this does probably carry over to
>> > WithIdentity/WithoutIdentity or whatever they are called. The question I
>> > think is still open (to me) is whether there really are active contractual
>> > implications of being identityless or if it's equivalent to being
>> >
>> "identityless objects and the type hierarchy": discussed how the
>> IdentityObject/PrimitiveObject interfaces are used in the "Consolidating the
>> user model" world
>
>
> For the moment I think this does probably carry over to
> WithIdentity/WithoutIdentity or whatever they are called. The q
Thanks for this write up John - it covers the space really well.
Digging a little bit into the need for a pivot field by emphasizing
two points in your email:
> The simplest way to support null is just to do what
> we do today, and buffer on the heap, with the option
> of a null reference instead
On Thu, Sep 9, 2021 at 5:32 PM Dan Smith wrote:
>
> On Sep 9, 2021, at 1:13 PM, Dan Heidinga wrote:
>
> but to keep the door open to having both factories and
> constructors in identity classes, should we use a different syntax for
> factories in primitive classes now? That w
hat's true at the
source level. Can you confirm?
More responses in line.
> > On Sep 9, 2021, at 10:15 AM, Dan Heidinga wrote:
> >
> > On Thu, Sep 9, 2021 at 10:24 AM Dan Smith wrote:
> >>
> >> JEP 401 includes special JVM factory methods, spelled (or,
>
On Thu, Sep 9, 2021 at 10:24 AM Dan Smith wrote:
>
> JEP 401 includes special JVM factory methods, spelled (or,
> alternatively, with a non-void return), which are needed as a
> standardized way to encode the Java language's primitive class constructors.
>
> We have a lot of flexibility in how
And continuing on the "long-overdue" theme, here's my long-overdue
review of the spec changes.
A big thank you to you, Dan S., for the careful spec writeup efforts.
I think this captures our discussions well.
--Dan
== Section 2.11.5 Object Creation and Manipulation
> Create a new class instance:
As discussed during the EG meeting, I've pulled together some examples
[1] that change the classfile version number during retransformation
without changing anything else in the file. The results were a little
surprising to me in how different OpenJ9 and Hotspot behave in these
cases as I recall t
Sorry for the delayed response to this, I've gone back and forth on
whether it's worth pushing on this helper method or not and still
think it is.
>
> For comparison, the wrapper class constructors first got warnings in 9
> (2017), and can probably expect to get errors by 23 (2024). So, nah, I do
On Mon, Jun 7, 2021 at 3:00 PM Dan Smith wrote:
>
> > On Jun 7, 2021, at 9:13 AM, Dan Smith wrote:
> >
> > On the other side, I'm not that persuaded by the argument for urgency. We
> > want to encourage a slow migration from 'new Object()' to
> > 'SomeClass.newIdentity()'. It's not going to be
Quoting from several previous emails in this thread:
Brian said:
> I agree that we can introduce the new API point immediately. The 17 window
> hasn't even closed yet! But we'd have to get a move on. But realistically,
> we can expect it to be several years before we are comfortable erroring
ations or free space correctly. None of these cases
care about the Object itself. It's just something to occupy heap
space.
* allocating a unique object to use as a lock
Is there some other pattern that suggests keeping `new Object()` at
the source level is worth the special cases in the model?
> I would strongly discourage new developers from saying "new Object()", and I
> think javac/IDEs should warn about it. It's allowed purely for compatibility.
> If developers insist on using it, then whether we've decreed that Object is
> abstract or not, they're going to need to learn that "new
I've added some comments to the document and thought I'd try something
different. Rather than copy/paste context here, I've opened a github
pull request against the repo so the context of the changes / comments
are directly inline.
https://github.com/openjdk/valhalla-docs/pull/1
Trying this but i
Thanks Dan for capturing the notes and leading the discussion.
I want to highlight a couple of other concerns that were raised during the
call:
* Precedent? Are we setting a precedent by providing a tool to address
Valhalla migration compatibility for old class files? We often talk about
yester
we
> will likely have to adjust phrases like "primitive values" to something like
> "primitive objects", and "primitive types" to either "primitive value types"
> or "built-in primitive value types", depending on context. But most of the
One of the things that moved us away from the use of the term "value"
was the violence it would do to the Java and JVM specs. Has a similar
analysis been done on how using primitive objects will affect the
existing specs?
--Dan
On Wed, Oct 7, 2020 at 6:19 AM Remi Forax wrote:
>
> I'm fine with
It either needs to be nominal for consistency so the name is stable for
stacktraces, Class#getName(), & equality operations. Or we need to make it
explicitly non-nominal using something like a hidden class to ensure that
each send of the `new Ljava/lang/Object;` resulted in a newly created
hidden
(Sorry for breaking the threading - with the email change I can't respond
directly to the original email)
> API changes
>
> - Add a java.lang.IdentityObject interface. The interface has no members
(don't want to disrupt method
> resolution, etc., in any way). The javadoc, for information purposes
(Sorry for breaking the threading - with the email change I can't respond
directly to the original email)
> API features
>
> (Optionally) The method Class.Interfaces(), and similar reflection API
points, filters out IdentityObject when it is not explicitly named in the
class file.
Like Peter, I'm
64 matches
Mail list logo
