Re: Value types - compatibility with existing “value objects”

[Vitaly Davidovich]

Yes I fully understand that this would be invisible, but that's part of the
"issue".  It's funny you mention layout; see @Contended and ObjectLayout
discussions for examples of where people care :).  The problem is that
people who are sensitive to performance (and that group is likely to care
more about this feature than others) care about these "invisible" details.
When you guys engineer the VM, do you care about how the OS implements
certain things or brush it off as invisible? If you don't have or want to
share the details now, that's fine too.

Sent from my phone
On Jan 8, 2015 2:17 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> How would the box be created in this case? Would it be a "view" over
>> the memory range covered by biggie inside the Foo instance?
>>
>
> These would be invisible to you, just like 99% of the representational
> decisions the VM makes on your behalf with all sorts of other things (e.g.,
> field layout).  For some extreme cases, we expose tuning flags, but that is
> definitely not our default.
>
>  I'm not even sure it's a good idea (at least for v1) to make any
>> promises around tearing/atomicity of value types.
>>
>
> Not an option.  There are security implications around structure tearing
> that we can't brush under the rug.
>
>