On 2012-10-18, at 6:36 PM, Remi Forax wrote:
>> Offhand, I don't know of any library code that manipulates Integers as
>> Integers and makes any sort of promises about their reference identity,
>> except for the nonsense about small-value interns (which we probably
>> replicate, because it is
On 10/18/2012 03:20 PM, David Chase wrote:
> Note: I did go back through the archives for a few months to see if I had
> missed some earlier discussion of this. Is there an even earlier discussion
> that I missed?
John has written a long blog post about value type this year,
https://blogs.or
Note: I did go back through the archives for a few months to see if I had
missed some earlier discussion of this. Is there an even earlier discussion
that I missed?
On 2012-10-18, at 3:21 AM, Remi Forax wrote:
> You can't forget backward compatibility. In Java 9, a program that was
> written
On 10/17/2012 10:41 PM, David Chase wrote:
> On 2012-10-17, at 2:12 PM, Remi Forax wrote:
>>> But we can't rely on this, hence it is not a true type property. But we
>>> could make it be as-if.
>>> I think I have to assume some sort of a marker class ("implements
>>> PermanentlyLockable").
>> A
On 2012-10-17, at 2:12 PM, Remi Forax wrote:
>> But we can't rely on this, hence it is not a true type property. But we
>> could make it be as-if.
>> I think I have to assume some sort of a marker class ("implements
>> PermanentlyLockable").
>
> A bit in the class header (equivalent to implem
On 10/17/2012 05:23 PM, David Chase wrote:
> On 2012-10-16, at 5:14 AM, Remi Forax wrote:
>
>> Frozen/locked is a runtime property, not a type property so it's harder
>> that that.
>> You have to do a frozen check at the beginning of the method and pray
>> that people
>> will only use it with froz
On 2012-10-16, at 5:14 AM, Remi Forax wrote:
> Frozen/locked is a runtime property, not a type property so it's harder
> that that.
> You have to do a frozen check at the beginning of the method and pray
> that people
> will only use it with frozen object and not a not frozen one because in
>
On 10/16/2012 09:48 AM, John Rose wrote:
> On Oct 14, 2012, at 2:25 PM, Remi Forax wrote:
>
>> A value object is a true immutable object so the
>> JIT can constant fold field access or merge redundant access even if
>> there is method call between them but for that the JIT has to insert a
>> check
On Oct 14, 2012, at 2:25 PM, Remi Forax wrote:
> A value object is a true immutable object so the
> JIT can constant fold field access or merge redundant access even if
> there is method call between them but for that the JIT has to insert a
> check to know if the object is frozen (definitively
I'm trying to summarize the ideas, this patch provides a way to mark in
the object header if an object is a value object or not. So the JIT or
the interpreter can check at runtime if an object is a value object and
perform optimizations. A value object is a true immutable object so the
JIT can
10 matches
Mail list logo
