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 opti
On Feb 3, 2015, at 9:13 AM, Vitaly Davidovich
mailto: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 restrictions, caveats,
> On Feb 3, 2015, at 12:20 PM, Vitaly Davidovich 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, for those
>
>
> But even if #2 is solved somehow for some subset of instantiations that
> the VM can auto-magically determine can be converted to a "placement-new"
> sort of allocation / construction sequence, there are plenty of final field
> assignment cases where the final ref field refers to an object that
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
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 wrote:
> A couple of
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 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 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
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
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
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 wrote:
>> Qu
Hi Daniel,
thanks a lot for sharing your point of view.
I haven't been aware of the fact that Project Panama is also working
on similar topics (I always thought it is only about the Foreign
Function Interface and the next generation JNI). In [1,2] John Rose
nicely explains that new data layouts i
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 m
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
develope
ask for feedback in case you think
I've totally misunderstood something. Of course any comments and
additional information is highly welcome as well.
1. JEP 169: Value Objects [1]
- Created by John Rose in 2012 (last update in Sep. 2014)
- Still in "Draft" state
- Proposes a new "
On 11/08/2012 05:47 AM, John Rose wrote:
> On Nov 7, 2012, at 5:12 PM, Remi Forax wrote:
>
>> please the name 'locked object' should be changed,
>> first because the fact that the value object uses bits also used to bias
>> a lock
>> is just an implementation detail and the name is too close to
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 08.11.2012 03:36, schrieb BGB:
> On 11/7/2012 7:02 PM, Remi Forax wrote:
>> On 11/07/2012 11:30 PM, BGB wrote:
>>> On 11/7/2012 4:15 PM, Vitaly Davidovich wrote:
Hi John,
Nice to see this effort moving forward. While reading
th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 08.11.2012 02:29, schrieb Jim Laskey:
> +1
I think frozen is very descriptive.
+1
>
> On 2012-11-07, at 9:16 PM, Vitaly Davidovich
> mailto:vita...@gmail.com>> wrote:
>
>> How about frozen?
>>
>> Sent from my phone
>>
>> On Nov 7, 2012 8:15 P
"Frozen" would be great I think, and it will definitely please the Rubyists
:-)
- Julien
On Thu, Nov 8, 2012 at 2:12 AM, Remi Forax wrote:
> On 11/07/2012 10:35 PM, John Rose wrote:
> > Thanks! This will move the conversation forward.
> >
> > -- John (on my iPhone)
>
> John, Mark,
> please t
On Nov 7, 2012, at 5:12 PM, Remi Forax wrote:
> please the name 'locked object' should be changed,
> first because the fact that the value object uses bits also used to bias
> a lock
> is just an implementation detail and the name is too close to
> synchronized/j.u.c.l.Lock.
>
> why not steady
On 11/7/2012 7:02 PM, Remi Forax wrote:
> On 11/07/2012 11:30 PM, BGB wrote:
>> On 11/7/2012 4:15 PM, Vitaly Davidovich wrote:
>>> Hi John,
>>>
>>> Nice to see this effort moving forward. While reading the JEP, I
>>> can't help but think how complicated this sounds for JVM
>>> implementors. Is in
+1
On 2012-11-07, at 9:16 PM, Vitaly Davidovich wrote:
> How about frozen?
>
> Sent from my phone
>
> On Nov 7, 2012 8:15 PM, "Remi Forax" wrote:
> On 11/07/2012 10:35 PM, John Rose wrote:
> > Thanks! This will move the conversation forward.
> >
> > -- John (on my iPhone)
>
> John, Mark,
>
How about frozen?
Sent from my phone
On Nov 7, 2012 8:15 PM, "Remi Forax" wrote:
> On 11/07/2012 10:35 PM, John Rose wrote:
> > Thanks! This will move the conversation forward.
> >
> > -- John (on my iPhone)
>
> John, Mark,
> please the name 'locked object' should be changed,
> first because t
On 11/07/2012 10:35 PM, John Rose wrote:
> Thanks! This will move the conversation forward.
>
> -- John (on my iPhone)
John, Mark,
please the name 'locked object' should be changed,
first because the fact that the value object uses bits also used to bias
a lock
is just an implementation detail
On 11/07/2012 11:30 PM, BGB wrote:
> On 11/7/2012 4:15 PM, Vitaly Davidovich wrote:
>>
>> Hi John,
>>
>> Nice to see this effort moving forward. While reading the JEP, I
>> can't help but think how complicated this sounds for JVM
>> implementors. Is introducing bytecodes and new value type
>>
On 11/7/2012 4:15 PM, Vitaly Davidovich wrote:
Hi John,
Nice to see this effort moving forward. While reading the JEP, I
can't help but think how complicated this sounds for JVM
implementors. Is introducing bytecodes and new value type
representation definitely a nonstarter? I'm thinking a
Hi John,
Nice to see this effort moving forward. While reading the JEP, I can't
help but think how complicated this sounds for JVM implementors. Is
introducing bytecodes and new value type representation definitely a
nonstarter? I'm thinking a setup akin to the CLR.
I certainly understand the a
Thanks! This will move the conversation forward.
-- John (on my iPhone)
On Nov 7, 2012, at 1:25 PM, mark.reinh...@oracle.com wrote:
> Posted: http://openjdk.java.net/jeps/169
>
> - Mark
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mai
Posted: http://openjdk.java.net/jeps/169
- Mark
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
31 matches
Mail list logo
