JEP 169: Value Objects

[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...


> 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