JEP 169: Value Objects

[Noctarius]

-----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
>>>> 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 attraction of keeping bytecode
>>>> the same, but wouldn't it make the JVM impl more
>>>> straightforward (and thus more robust, stable,
>>>> performant, etc) if value types/structs were first class
>>>> citizens?
>>>> 
>>>> I'm sure you've thought about this plenty so I'm mostly
>>>> curious to hear your take on the tradeoffs and generally
>>>> on how you think this approach will shake out.
>>>> 
>>> agreed, though it need not be "that" bad (probably it would
>>> be mostly handled by a dynamic check on the reference or on
>>> the object?).
>>> 
>>> 
>>> I think it would be nice if, say, a particular class could
>>> be marked as "lockPermanently", so any new instances of the
>>> given class would have this property by default.
>>> 
>>> like, say, if we could do something like: @LockPermanently 
>>> public class Foo ...
>>> 
>>> or: @ValueClass public class Foo ...
>>> 
>>> this could be partly so that the JVM could look at the
>>> class and be like "hey, this class is always locked" and
>>> possibly optimize it a little more aggressively.
>>> 
>>> otherwise, things would mostly be as-is (the ability to do
>>> this on a per-instance basis is an interesting idea...).
>> that the basic idea but then you want array of value type
>> ... then you want ArrayList of value type ... then you want
>> to retrofit wrapper type like j.l.Integer, j.l.Double etc, to
>> be value type when it's possible ... and after having
>> duplicated the whole world to have one version for reference
>> object and one for value object, you may think that tagging
>> object at runtime as proposed is perhaps a better idea. yes,
>> you will have to add some dynamic check (leading to a deopt)
>> but that the price to pay to avoid the duplication mess.
> 
> could be, however, the above is assuming that the only
> available option were the static case.
> 
> very possibly, the actual implementation would be as the
> dynamic case, and the dynamic case would probably still be
> usable as well, but the static case would exist mostly as an
> additional optimization hint, as well as potentially to reduce
> the typing required to create an object (because it could be
> handled more automatically, say, it auto-locks when "<init>"
> finishes or similar, like the JIT reacts specially to the 
> presence of the annotation or similar).
> 
> either way works I guess though...
> 

I would suggest both options. For new classes where I know that it
will be a value type it would be nice to permanently mark it as this.


> 
>> Rémi
>> 
>>> 
>>>> Thanks
>>>> 
>>>> Sent from my phone
>>>> 
>>>> On Nov 7, 2012 4:36 PM, "John Rose"
>>>> <john.r.rose at oracle.com <mailto:john.r.rose at oracle.com>>
>>>> wrote:
>>>> 
>>>> Thanks!  This will move the conversation forward.
>>>> 
>>>> -- John  (on my iPhone)
>>>> 
>>>> On Nov 7, 2012, at 1:25 PM, mark.reinhold at oracle.com 
>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>> 
>>>>> Posted: http://openjdk.java.net/jeps/169
>>>>> 
>>>>> - Mark
>>>> _______________________________________________ mlvm-dev
>>>> mailing list mlvm-dev at openjdk.java.net
>>>> <mailto:mlvm-dev at openjdk.java.net> 
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________ mlvm-dev
>>>> mailing list mlvm-dev at openjdk.java.net 
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> 
>>> 
>>> _______________________________________________ mlvm-dev
>>> mailing list mlvm-dev at openjdk.java.net 
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> _______________________________________________ mlvm-dev
>> mailing list mlvm-dev at openjdk.java.net 
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________ mlvm-dev
> mailing list mlvm-dev at openjdk.java.net 
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 


- -- 


##############################
# A Digital's Life           #
##############################
Nickname: Noctarius
Location: Germany

Meet me at:
Ohloh: http://www.ohloh.net/accounts/noctarius
Web: http://www.noctarius.com
XMPP/Jabber: noctarius at jabber.ccc.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQm35UAAoJEH/g+YBfahrqRTYP/0hH7if0xzWU6P9c+oT278yA
nWiIa5/AHUFIrbZtS/HWg9InD5WjrvumHSxIPnDnVC5TqhiY7+2HHY8bUnJHe0lL
sWRGTMpV2bPBSiyRG9Yr0hEjpp5erke/y7rVAoq71AqoJwritHGi1O63Alb8FuJz
ZR2qlR5ykw0sHOX8b0+xb8MAcfmVgmcX1dJYH7uwkyZHN4RoJbxq9ED6cK+4Wa+4
EQylFxK5E0gKnUHpE19spK4pvVFy8UV1R02CqAdSnzB0MEY5BeHtu5osASZBPfsl
ul0ib0CVy3CY3AtkiLqoKJtoZBxLgf3WBesJMhrozl/f3qDJ6MZNI+zjNJp9x+DH
hIjl10UE7oOMBx3L7TlcNu+mu/5W0nQSSzP+UD5zSOI1qmORhnaT1rgWEzOr2X1a
Vi5CTkJbCaZZVAHZ3FppfaZUtg+morlhv+pal8nHhMfw28Ui48APTygtbg0nEWgv
tcpgqs9jH14etRfMZdVcRIvuuXcjjw5v0kcuzi1PrK8XnXODNJVS6SkCAbXPe1jz
QiXz6PwEhkZ9QAf1lQa1i+ur3KqoLTYXyhmIQT0PvFIlZ1cpsjgJ/6Inic9g37Cy
Llk1bdA2+3xfWI6u+avTZg9cy9qi6M/sMALRLZzmAMgMFJDGMeELB/CT2xdM4xGp
honp+8QcOUf+hO+ADAs+
=IA0d
-----END PGP SIGNATURE-----