On Feb 3, 2015, at 12:20 PM, Vitaly Davidovich vita...@gmail.com wrote:
1) My assumption is that vast majority of classes will benefit from inline
storage of their collaborators. The waste would be in classes that have hot
and cold members together, but I think that's the minority? But,
On Feb 3, 2015, at 9:13 AM, Vitaly Davidovich
vita...@gmail.commailto:vita...@gmail.com wrote:
Gil, not sure if you saw my reply to Volker, but I agree -- I was simply asking
why request this optimization via explicit syntax and not do it automatically
in the runtime (with all the same
A couple of point here, specific to org.ObjectLayout (http://objectlayout.org):
Declaration:
The ObjectLayout @Intrinsic (http://objectlayout.org) annotation is used for
declaring what you refer to as inline objects. It is specifically not
intended to be a layout control directive, but an
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
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
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,
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
Gil, not sure if you saw my reply to Volker, but I agree -- I was simply
asking why request this optimization via explicit syntax and not do it
automatically in the runtime (with all the same restrictions, caveats, fine
print, etc).
On Tue, Feb 3, 2015 at 11:58 AM, Gil Tene g...@azulsystems.com
1) My assumption is that vast majority of classes will benefit from inline
storage of their collaborators. The waste would be in classes that have
hot and cold members together, but I think that's the minority? But, for
those cases, it would be beneficial to allow out-of-band layout (i.e.
today's
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
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.
The Value types for Java approach clearly seems to be the most
general but also the most
Am 29.01.2015 12:02, schrieb Daniel Latrémolière:
I just want to quickly summarize my
current findings here and gently ask for feedback in case you think
I've totally misunderstood something. Of course any comments and
additional information is highly welcome as well.
I don't know if that can
I just want to quickly summarize my
current findings here and gently ask for feedback in case you think
I've totally misunderstood something. Of course any comments and
additional information is highly welcome as well.
I don't know if that can be useful, but here is my point of view of
13 matches
Mail list logo
