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
