Right, but I'm talking about using same restrictions that ObjectLayout
requires (private final fields initialized inside constructor). I guess an
easy way to describe it as "do same thing automatically that would be done
manually using ObjectLayout".
sent from my phone
On Feb 3, 2015 11:53 AM, "Volker Simonis" <volker.simo...@gmail.com> wrote:
> Hi Vitaly,
>
> I don't think what you propose could be done in general. References
> are polymorphic, i.e. you could have:
>
> class Point { int x, y; }
> class Line { Point p1, p2;}
>
> Now how could you inline p1 and p2 into a Line object when you also have:
>
> class Point3D extends Point { int z; }
>
> You could of course only inline objects of final classes which are
> directly derived from Object. But I think if you really carefully
> reason about all the consequences (which doesn't imply that I've done
> this :) you will finally get to something similar like the
> ObjectLayout library.
>
> Regards,
> Volker
>
>
> On Tue, Feb 3, 2015 at 5:40 PM, Vitaly Davidovich <vita...@gmail.com>
> wrote:
> > Hi Volker,
> >
> > Sorry, I may have been unclear in my question. As you say, ObjectLayout
> > requires that you annotate the fields that you'd like inlined and then
> also
> > use special API to construct those objects. I'm wondering whether,
> > instead, all private final fields are automatically inlined, and only
> cases
> > where you'd like to layout the field out-of-band would require
> annotation.
> > This would be controlled via a cmdline flag, as you say, similar to
> perhaps
> > how compressed oops are enabled (or not). Note that I'm talking about
> > purely layout of reference types, not value types.
> >
> > The "concern" with having to explicitly annotate and use dedicated APIs
> to
> > opt-in is that adoption will be fairly low, whereas I think most of the
> > time one would want inlined storage layout.
> >
> > Thanks
> >
> >
> > On Tue, Feb 3, 2015 at 11:29 AM, Volker Simonis <
> volker.simo...@gmail.com>
> > wrote:
> >
> >> Hi Vitaly,
> >>
> >> for PackedObjects/ObjectLayout you need to specially annotate the
> >> classes and/or fields which you want to allocate "inline". Once you've
> >> done that you have no choice with the PackedObjects approach.
> >> ObjectLayout is a little special here, because it can run with any
> >> Java VM in which case it will still use the default reference model.
> >> But it can potentially be optimized by some VM's to provide the flat
> >> object layout. I expect these optimizations to be controllable by a
> >> command line option.
> >>
> >> With the "Value Types for Java" [1] approach you'll have the
> >> possiblitly to express the behavior right in Java like in the
> >> following example from [1]:
> >>
> >> final __ByValue class Point {
> >> static Point origin = __MakeValue(0, 0);
> >>
> >> I think the default will always be "reference semantics" in Java but
> >> with various degrees of freedom to optionally choose value semantics.
> >>
> >> Regards,
> >> Volker
> >>
> >> [1] http://cr.openjdk.java.net/~jrose/values/values-0.html
> >>
> >> On Mon, Feb 2, 2015 at 9:19 PM, Vitaly Davidovich <vita...@gmail.com>
> >> wrote:
> >> > 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.simo...@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.go...@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@openjdk.java.net
> >> >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > mlvm-dev mailing list
> >> > mlvm-dev@openjdk.java.net
> >> > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> >> >
> >> _______________________________________________
> >> mlvm-dev mailing list
> >> mlvm-dev@openjdk.java.net
> >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> >>
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
