<div dir="ltr"><div dir="ltr">On Fri, Jul 22, 2022 at 4:16 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>Now I wonder if these points, at least, might be uncontroversial:</div>
<div><br>
</div>
<div>1. There exist useful well-defined concepts of "value" and "object" that are disjoint and that *have been* valid up to now. (I'll hazard a claim that my paper still defends at least
<i>this</i> much well enough.)</div>
<div>2. Also, you've had to treat the two quite differently from each other in your programs.</div>
<div>3. We *are* changing (improving) #2 through this project.</div>
</div>
</div>
</blockquote>
<div>I claim we are changing #1 as well, though to a lesser degree.  #2 should “mostly go away”; #1 should transform into other terms, such as e.g. “object stored directly” vs “reference to object”.  It is those other terms that I think we are searching for
 consensus on, but #1 is moving.</div></div></div></blockquote><div><br></div><div><br></div><div>#1 is only addressing the fact that something *has been* true thus far, which is not something we can change. It was supposed to be easy common ground. :-)</div><div>It sounds to me like you are really alluding here to the A vs B distinction below?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>4. But users may still need #1's disjoint concepts when they are trying to reason about the *performance* model (tho they'll also need to understand that the VM is empowered to "fake" one as the other when the spirit so moves it).</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, though I think these are concepts that are more _derived from_ the distinction in #1.  John’s notion of “placement” is good here; the choice of ref vs val constrains the placement, and placement informs the performance model.  I think part of what
 has been missing until today is a good attempt to name the intermediate actors, like placement.  I hope that if we refine those terms a bit, things will get clearer.  </div></div></div></blockquote><div><br></div><div><br></div><div>In my attempts to flesh out and understand "your model" (which I attempted to describe as "A" below and which I've called "VAO" in the past for "values are objects", vs. my preferred model "VANO"), I will indeed adopt this helpful term "placement".</div><div><br></div><div>A reason why I resist this model so much: to me this is like saying that the difference between a giraffe and a drawing of a giraffe is just where the giraffe is "placed". It feels like more than that. One has its own independent existence, possibly even changing over time, and the other is just this freely copyable snapshot of information, each copy wholly dependent on the medium it's drawn on. That feels like a very fundamental distinction to me, and it has a good physicality to it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div><div dir="ltr"><div>5. The questions at hand in this thread are not foremost about the performance model but about the basic "start-here" user model.</div>
<div>6. These miiight be fair descriptions of the 2 camps?</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>A. Because you'll get to program mostly the same way in both cases, we can and should de-emphasize the distinction. There might be a reference sitting in between you and the data/"object" or there might not. It's mostly in the VM's hands. If you
 ever think you care about the distinction, you probably are dipping down into the performance model. There is a "just don't worry about it!" flavor to this option.</div>
<div>B. It's still helpful to have a solid sense of the distinction, even as we benefit from getting to code the same way to each. Even though the VM might really fake one as the other; again, that's performance model.</div>
</blockquote>
<div><br>
</div>
<div>Anything controversial about the above?</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>No, and I want to choose both A and B!  I don’t think they are opposed, I think they are different angles on the elephant.  </div></div></div></blockquote><div><br></div><div><br></div><div>I strongly suspect that trying to have a thing like this both ways may be exactly where we inject the most confusion.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div dir="ltr"><div>(If I had to explain why I've been so dogged about B, maybe it's the sense that we simply won't "get away with" A. It feels hard (to me) to tell users simultaneously that they should stop caring about a distinction AND that we're changing up how
 all kinds of stuff works across that distinction. It feels more solid to firm up the distinction so that we can talk about how things are changing, and then let that distinction just slowly matter less and less over time.)</div></div></blockquote>
<div>Agree that we need a good "start here” story, but I think a good one will have aspects of A and B.  I think we’re making progress?</div></div></div></blockquote><div><br></div><div><br></div><div>Yes, progress.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Jul 22, 2022 at 12:02 PM John Rose <<a href="mailto:john.r.rose@oracle.com" target="_blank">john.r.rose@oracle.com</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">
<u></u>
<div>
<div style="font-family:sans-serif">
<div style="white-space:normal">
<p dir="auto">On 22 Jul 2022, at 10:55, Brian Goetz wrote:</p>
</div>
<div style="white-space:normal">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)">
<p dir="auto">…</p>
</blockquote>
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(153,153,153);color:rgb(153,153,153)">
<p dir="auto">So then, would we call an instance of `Complex.val` a "non-heap object" or an "inlined object" or what? We need to flesh out a whole lexicon. The phrase "value object" becomes useless for this particular distinction as it will apply to
 both.</p>
</blockquote>
<p dir="auto">Yes, in the taxonomy I’m pushing, a “value object” is one without identity, and is the kind of object you can store directly in variables without going through a reference. But I don’t think that there are instances of Complex.val and
 instances of Complex.ref; I think there are instances of *Complex*, and multiple ways to describe/store/access them.</p>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">FTR, I enthusiastically agree with this viewpoint, even though I am also probing for weaknesses and alternatives. (FTR I feel the same about Brian’s summary in his previous short message.)</p>
<p dir="auto">And under this viewpoint, the terms “instance” and “object” have the same denotation, though difference connotations. (When I say “instance” you may well think, “instance of what”? But you don’t ask that question so much if I say “object”.)</p>
</div>
<div style="white-space:normal">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(153,153,153);color:rgb(153,153,153)">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(187,187,187);color:rgb(187,187,187)">
<p dir="auto">That `int/Integer` decision you've been making has always been between (1) value and (2) (reference-to) object, and that decision is still exactly between (1) value and (2) (reference-to) object now, and btw the definitions of 'reference'
 and 'object' remain precisely wedded to each other as always.</p>
</blockquote>
<p dir="auto">The "heap object" alternative strikes me (and I am trying to be fair, here) as:</p>
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(187,187,187);color:rgb(187,187,187)">
<p dir="auto">Now, that's an object either way, and you're going to apply that old thought process toward which *kind* of object you mean, either a (1) "inline object" or a (2) "(reference-to) heap object". It's now just heap objects and references
 that are paired together.</p>
</blockquote>
</blockquote>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">I think, Kevin, you are going wrong at this point: It’s not a
<em>kind</em> of object, it is a <em>placement</em> of an object. What “kind” of person am I when I am diving to the office? Surely the same “kind” as when I am at home. But when I am driving, I am equipped with a car and a road, much like
 a heap-placed object is equipped with a header and references.</p>
<p dir="auto">Likewise, an int/Integer is (in Valhalla) the same “kind” of object (if we go all the way to making primitives be honorary objects) whether it is placed in heap or on stack or inside another object.</p>
<p dir="auto">The distinction that comes from the choice of equipping an int with a header in heap storage is a distinction of placement (and corresponding representation). So an int/Integer does not intrinsically have a header because it is an object
 (because of its “kind”). It <em>may</em> have a header if the JVM needs to give it one, because it is stuck in the heap.</p>
<p dir="auto">(My points about int/Integer could partly fail if we fail to align int and Integer in the end. So transfer the argument to C.val/C.ref if you prefer. It is the same argument.)</p>
<p dir="auto">And I would say the <em>placement</em> of an object is in three broad cases which are worth teaching even to beginners:</p>
<ul>
<li>
<p dir="auto">“in the heap”: therefore referred to by a machine word address, and presumably equipped with a header and maybe surrounded by some alignment waste; a JVM might have multiple heaps but at this level of discourse we say “the heap”</p>
</li><li>
<p dir="auto">“on the stack”: therefore manipulated directly by its components, which are effectively separated into scalars (it is “scalarized”, we sometimes say); we might sometimes wish to say “JVM stack or locals” instead of “stack”, or, with increasing
 detail, “on stack, in locals, and/or in registers, and/or as immediates in the machine code”</p>
</li><li>
<p dir="auto">“contained in another object”: in a field or array element, therefore piggy-backing on the other object’s placement; and note that even arrays are scalarized sometimes, lifting their elements into registers etc.</p>
</li></ul>
<p dir="auto">To summarize: <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">
Placement = Heap | Stack | Contained[Placement]</code>.</p>
<p dir="auto">One might use the term “inline” somewhere in there, either to mean
<code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">
Contained</code> or <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">
Stack|Contained[*]</code>.</p>
<p dir="auto">Static field values are a special case, but they can be classified in one of the above ways. HotSpot places static fields inside a special per-class object (the mirror, in fact), so their values are either contained or separate in the
 heap (JVM’s choice again).</p>
<p dir="auto">One might be pedantic and say that an instance can be contained “in static memory” (neither heap nor stack) if the JVM implements storage for static fields outside of the heap. But in that case I’d rather say that they are in a funny
 corner of the heap, where perhaps headers are not needed, because some static metadata somewhere dictates what is stored.</p>
<p dir="auto">(Hence I like to be cagey about whether a heap-object actually has a physical header. It might not in some JVM implementations.)</p>
</div>
<div style="white-space:normal">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)">
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(153,153,153);color:rgb(153,153,153)">
<p dir="auto">Starting to prefer the first way (as I did) did not feel like going rogue: after all, did we not gravitate toward ".ref" and ".val" as our placeholder syntaxes, not ".inline" and ".heap" or anything else?</p>
</blockquote>
<p dir="auto">With you on this. I think asking users to reason about “heap objects” vs “inline objects” is pushing them towards the implementation, not the concepts. They may have to reason about this to understand the performance model, but that’s
 already advanced material.</p>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">Yes. And even more specifically in the implementation, users who think about “heap objects” are really (IMO) trying to predict the
<em>placement</em> of the objects, <em>where</em> the JVM will choose to place their bits in physical memory.</p>
<p dir="auto">This question of placement is very interesting to the “alert” performance-minded programmer. Not every programmer is in that state; for me I try to practice “first make it work then make it fast”. I get “alert” to performance only in
 the “make it fast phase”, a phase which many of my codes never reach.</p>
<p dir="auto">As a sort of “siren song” the question of placement is <em>
also</em> interesting to the beginning student who is struggling to build a mental image of Java data, and is reaching for visualizations in terms of memory and addresses, or (what is about the same) boxes and arrows. But the JVM will make a hash of all that,
 if it is doing a good job. So the student must be told to hold those mental models lightly.</p>
<p dir="auto">Kevin is insisting (for his own good reasons) on his answer to “where are the objects”: They are always “in the heap” and thus “with headers, accessed by pointers”. I suspect (but haven’t seen from Kevin himself yet) that this is in part
 due to a desire to work with, rather than work against, the student’s desire to make simple visual models of Java data.</p>
<p dir="auto">Crucially, in a literal “boxes and arrows” model, an arrow (perhaps a
<code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">
C.ref</code> reference to an instance) looks very different from a nested box (perhaps a
<code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">
C.val</code> instance), and the naive user might insist that such differences are part of the contract between the user and the JVM. But they are not. The JVM might introduce invisible “arrows” (because of heap buffering) and it might remove arrows (because
 of scalarization for a number of possible reasons).</p>
<p dir="auto">So if the student is told that the arrows and boxes are “what’s really going on” the student using that assurance to predict performance and footprint will feel cheated in the end.</p>
<p dir="auto">To summarize: Any given instance/object has logically independent properties of class and placement.</p>
<p dir="auto">And thus: The choice of companion type does not affect class but may (may!) affect placement.</p>
<p dir="auto">Circling back to the language design, it might seem odd that there are three ways to place an object but just two companion types. But this oddness goes away if you realize that
<code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">
C.val</code> and <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">
C.ref</code> are not placement directives. The choice between the two is a net-binary selection from a sizeable menu of “affordances” that the user might be expecting or disavowing at any given point in the code. (See my lists of “affordances” and “alternative
 affordances” in <a href="http://cr.openjdk.java.net/~jrose/values/encapsulating-val.html#affordances-of-c.ref" style="color:rgb(57,131,196)" target="_blank">
encapsulating-val</a>.)</p>
<p dir="auto">The user is given this simplified switch to influence the JVM’s decisions about placement (and therefore representation). It is useful because the JVM can employ different implementation tactics depending on the differences between the
 user-visible contracts of <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">
C.ref</code> and of <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">
C.val</code>. In the choice of implementation tactics, the JVM has the final say.</p>
</div>
</div>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif">
<span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java
 Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div></div>