What's the status of / relation between "JEP 169: Value Objects" / "Value Types for Java" / "Object Layout"

Vitaly Davidovich vitalyd at gmail.com
Mon Feb 2 20:19:09 UTC 2015


Volker (or anyone else for that matter),

Just curious -- do you envision "inline" layout of objects as something one
would have to opt-in or as the default layout for all objects in a heap? It
seems like this should be the default (assuming zero to minimal overhead
for loading the references) as I think wanting "out of line" allocations is
more rare.

Thanks

On Mon, Feb 2, 2015 at 2:06 PM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi Brian,
>
> thanks a lot for your detailed answer and apologies for the late reply
> (I was a little distracted by FOSDEM :)
>
> All your comments have been clear and reasonable and are much
> appreciated. Please find my additional answers inline:
>
> On Thu, Jan 29, 2015 at 6:05 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
> >> Question: is JEP 169 still under active development or has it been
> >> merged into the more general "Value types for Java" proposal below?
> >
> >
> > It has been merged into the more general Value Types for Java proposal.
> >
>
> Then maybe this JEP should be closed to avoid further confusion?
>
> >> The "Value types for Java" approach clearly seems to be the most
> >> general but also the most complex proposal.
> >
> >
> > For some meanings of "complex".  It is certainly the most intrusive and
> > large; new bytecodes, new type signatures.  But from a user-model
> > perspective, value types are actually fairly simple.
> >
> >> It's out of scope for Java
> >> 9 and still questionable for Java 10 and above. The "PackedObject" and
> >> "ObjectLayout" approaches are clearly simpler and more limited in
> >> scope as they only concentrate on better object layout.
> >
> >
> > To your list, I'd add: Project Panama, the sister project to Valhalla.
> > Panama focuses on interop with native code and data, including layout
> > specification.  A key goal of Packed was to be able to access off-heap
> > native data in its native format, rather than marshalling it across the
> JNI
> > boundary.  Panama is focused on this problem as well, but aims to treat
> it
> > as a separate problem from Java object layout, resulting in what we
> believe
> > to be a cleaner decomposition of the two concerns.
> >
>
> Your right. I somehow missed to look at Panama more deeply because I
> always thought it is only about FFI. John Rose nicely explains the
> various parts of Panama in this mail
> http://mail.openjdk.java.net/pipermail/panama-dev/2014-October/000042.html
> where he also mentions the intention of Panama to create new flatter
> data layouts in the Heap and the relation of Panama to PackedObjects
> and ObjectLayout.
>
> > Packed is an interesting mix of memory density (object embedding and
> packed
> > arrays) and native interop.  But mixing the two goals also has costs; our
> > approach is to separate them into orthogonal concerns, and we think that
> > Valhalla and Panama do just that.  So in many ways, while a larger
> project,
> > the combination of Valhalla+Panama addresses the problem that Packed
> did, in
> > a cleaner way.
> >
> >> Question: is there a chance to get a some sort of Java-only but
> >> transparently optimizable structure package like "ObjectLayout" into
> >> Java early (i.e. Java 9)?
> >
> >
> > It would depend on a lot of things -- including the level of readiness of
> > the design and implementation, and the overlap with anticipated future
> > features.  We've reviewed some of the early design of ObjectLayout and
> > provided feedback to the projects architects; currently, I think it's in
> the
> > "promising exploration" stage, but I think multiple rounds of
> simplification
> > are needed before it is ready to be considered for "everybody's Java."
> But
> > if the choice is to push something that's not ready into 9, or to wait
> > longer -- there's not actually a choice to be made there.
> >
> > I appreciate the desire to "get something you can use now", but we have
> to
> > be prepared to support whatever we push into Java for the next 20 years,
> and
> > deal with the additional constraints it generates -- which can be an
> > enormous cost.  (Even thought the direct cost is mostly borne by Oracle,
> the
> > indirect cost is borne by everyone, in the form of slower progress on
> > everything else.)  So I am very wary of the motivation of "well,
> something
> > better is coming, but this works now, so can we push it in?"  I'd prefer
> to
> > focus on answering whether this is right thing for Java for the next 20
> > years.
> >
> >> In my eyes this wouldn't contradict with a more general solution like
> >> the one proposed in the "Value types for Java" approach while still
> >> offering quite significant performance improvements for quite a big
> >> range of problems.
> >
> >
> > The goals of the ObjectLayout effort has overlap with, but also differs
> > from, the goals of Valhalla.  And herein is the problem; neither
> generalizes
> > the other, and I don't think we do the user base a great favor by
> pursuing
> > two separate neither-coincident-nor-orthogonal approaches.  I suspect,
> > though, that after a few rounds of simplification, ObjectLayout could
> morph
> > into something that fit either coincidently or orthogonally with the
> > Valhalla work -- which would be great.  But, as you know, our resources
> are
> > limited, so we (Oracle) can't really afford to invest in both.  And such
> > simplification takes time -- getting to that "aha" moment when you
> realize
> > you can simplify something is generally an incompressible process.
> >
> >> Question: what would be the right place to propose something like the
> >> "ObjectLayout" library for Java 9/10? Would that fit within the
> >> umbrella of the Valhalla project or would it be done within its own
> >> project / under it's own JEP?
> >
> >
> > Suggesting a version number at this point would be putting the cart
> before
> > the horse (you'll note that we've not even proposed a version number for
> > Valhalla; the closest we've gotten to that is "after 9".)
> >
> > OpenJDK Projects are a tool for building a community around a body of
> work;
> > JEPs are a project-management tool for defining, scoping, and tracking
> the
> > progress of a feature.  Given where OL is, it would be reasonable to
> start a
> > Project, which would become the nexus of collaboration that could
> eventually
> > produce a JEP.
> >
>
> That sounds reasonable. I'll speak with the ObjectLayout people to
> hear what they think about starting a new OpenJDK project.
>
> And after all you've said before, I also came to the conclusion that
> investigating ways of new in-heap object layouts seem to be better of
> in the Panama project. So I'll also ask there what they think about
> it. Maybe ObjectLayout could become part of Panama or maybe we could
> just start a new subproject of Panama with the same/similar goals.
>
> > Hope this helps,
> > -Brian
>
> It really did!
>
> Thanks again,
> Volker
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


More information about the valhalla-dev mailing list