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
