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
