Clarification on migration to value types and boxed vs unboxed representations

Michael Barker mikeb01 at
Tue Jan 6 19:56:07 UTC 2015

Apologies for continuing this thread, but I wanted to mention that those
who are interested in mutable structs should look at Gil Tene and Martin
Thompson's Object Layout proposal ( - which is
a complimentary feature to value types.  If you have questions, the best
place to ask would be on the mechanical sympathy mailing list (!forum/mechanical-sympathy).  Gil and
Martin regularly follow that list.


On 7 January 2015 at 06:26, Brian Goetz <brian.goetz at> wrote:

> Obviously both extremes (encase everyone in concrete, vs force-feeding
> chainsaws to schoolchildren) are ridiculous.  Which means we're in the
> middle, where judgement has to be used to determine a fair balance.  And
> since its subjective, there will be differences of opinion.  (And when
> there are differences of opinion, it is tempting to frame the "slightly
> more conservative than you" perspective as reactionary and the "slightly
> more liberal than you" perspective as communist, but that's not really
> constructive.)
> We do have escape hatches like Unsafe.  For exactly this purpose.  And
> they are clearly labeled as dangerous (hey, what does "unsafe" mean?) But
> mainstream mechanisms should be as safe and surprise-free as we can make
> them.
> There are arguments on both sides of the "mutable vs immutable" argument,
> but the "experts need mutable value types for performance" is pretty bogus,
> because it only looks at one side of performance.  Compare this to another
> similar performance story: direct access to pointers.  C programmers often
> claim that access to raw pointers is their secret weapon.  But, if *anyone*
> has access to raw pointers, the optimizer is crippled *for everyone*.
> (Many optimizations are only possible if the VM can control all the
> pointers, such as compacting GC.)  So giving a "secret weapon" to a small
> cadre of elite hax0rs completely reams the other 99.99% of users.  Which
> seems like a terrible tradeoff, especially given that VMs are better than
> all but the most elite of hax0rs (most of which, I'll point out, are
> working on VMs.)
> Mutable structs are basically the same tradeoff.  If you have mutable
> structs, you need a way to pass them by reference.  Not only does this add
> a whole new layer of complexity that Java never had, but now you have the
> problem of pointers to the *middle* of an object.  Said interior pointers
> make life much harder for the GC.  (GC performance on .NET trails badly
> behind Java, in part because of this very reason.)  So again, I think the
> "experts need mutable structs" argument is effectively throwing the other
> 99.99% of devs under the bus -- another bad tradeoff.
> If you're going to make performance arguments of the form "If I had tool
> X, I could do Y", then you have to include the other side, which is "if no
> one has tool X, what more can the VM do?"  And the answer is often
> surprising.
> Now, there are other arguments why we might consider mutable value types
> (and while this is a reasonable place for them, I'll just cut this off here
> as I'm not prepared to engage further on this subject now -- I have too
> many other things going on that I need to focus on, sorry.)
> On 1/6/2015 11:40 AM, Vitaly Davidovich wrote:
>> I was merely using unsafe as an example of a tool (lib, not language, in
>> this case) that's (relatively) rarely used, but very important for some
>> cases.  If you want to provide a Sufficiently Smart Compiler that makes
>> it obsolete, great, but that's not here presently and probably never
>> will be (it'll be good enough for majority of cases though).
>> One thing that really irks me (and I think some others, based on my
>> observations) about some of the discussions around java and its
>> direction is the sentiment that java developers require hand holding,
>> can't be trusted, must be fully abstracted away from the machine, and
>> thus deserve a language with *mandatory* safety belts and restraints.
>> If java wants to stay relevant in high perf domains, that sentiment
>> needs to be dropped; escape hatches/unsafe-ish code must remain
>> available.  Every language that I know of which markets itself as being
>> relevant in high perf scenarios allows for having small targeted amounts
>> of unsafe code; there's absolutely nothing wrong with that, and in fact,
>> it's a Good Thing.
>> As for mutable value types, showing developers the types of issues they
>> may face is fine, direct them towards immutability, but ultimately, let
>> them decide! (clearly, mutable value types aren't going to be
>> implemented, I'm not going to change your mind, but I dislike the
>> philosophy behind it).
>> On Tue, Jan 6, 2015 at 11:21 AM, Brian Goetz <brian.goetz at
>> <mailto:brian.goetz at>> wrote:
>>     If your comparison is that "mutable structs are like unsafe", great
>>     -- that's a bulletproof argument that value types must not be
>>     mutable, and there is no need for further discussion on the topic :)
>>     (Pause while Brian gets out his chisel to carve it in stone....done.)
>>     On 1/6/2015 10:24 AM, Vitaly Davidovich wrote:
>>         I've seen and read that blog before.  I'm not disputing that one
>>         needs
>>         to be careful in how C# mutable structs are used and as
>>         mentioned, it's
>>         a rare (but useful) use case.  But really, the issue in that blog
>> is
>>         more about how compiler desugars/transforms C#'s using block and
>> its
>>         poor interaction with value types when someone doesn't fully
>>         understand
>>         the sugaring mechanics.  I suspect the problem Eric (when he was
>>         still
>>         at MSFT) had was developers not taking the time to fully
>>         understand the
>>         tool.  Yes, it's error prone if you're sleep walking through
>>         code, but
>>         then again, don't sleep walk through code!
>>         So, I'll agree that their use should be restricted, but it's nice
>> to
>>         have when needed (akin to using com.sun.misc.Unsafe -- it's a
>> sharp
>>         knife that can inflict serious damage if not wielded carefully,
>>         but very
>>         handy/surgical when called for and used carefully).
>>         On Tue, Jan 6, 2015 at 10:13 AM, Brian Goetz
>>         <brian.goetz at <mailto:brian.goetz at>
>>         <mailto:brian.goetz at
>>         <mailto:brian.goetz at>__>> wrote:
>>              The C# folks concluded in hindsight that mutable structs
>>         was a big
>>              mistake.  See Eric Lippert's blog:
>> __14/to-box-or-not-to-box-that-____is-the-question.aspx
>>         <
>> 14/to-box-or-not-to-box-that-__is-the-question.aspx>
>>         <
>> 14/to-box-or-not-to-box-that-__is-the-question.aspx
>>         <
>> 14/to-box-or-not-to-box-that-is-the-question.aspx>>
>>              TL;DR version (last line): "Once again the moral of the
>>         story is:
>>              mutable value types are enough pure evil to turn you all
>>         into hermit
>>              crabs, and therefore should be avoided."
>>              On 1/6/2015 8:33 AM, Vitaly Davidovich wrote:
>>                  What are the "far too many" downsides? The lost writes
>> can
>>                  happen if not
>>                  careful, but what else? I'm assuming though if mutable
>>         value
>>                  types were
>>                  possible, then language and VM would allow passing them
>>         by ref.
>>                  Sent from my phone
>>                  On Jan 6, 2015 5:12 AM, "Stephen Colebourne"
>>                  <scolebourne at <mailto:scolebourne at>
>>         <mailto:scolebourne at <mailto:scolebourne at>>>
>> wrote:
>>                      On 6 January 2015 at 01:58, Vitaly Davidovich
>>                      <vitalyd at <mailto:vitalyd at>
>>         <mailto:vitalyd at <mailto:vitalyd at>>> wrote:
>>                          Mutable structs aren't used all that often in
>>         c# but
>>                          there are times when
>>                          they're very useful.
>>                      When I've thought about this, the first use case
>>         for mutable
>>                      I came up
>>                      with was property objects. These allow code like:
>>                      class Person {
>>                          public final Property<Strring> surname;
>>                      }
>>                      String surname = person.surname.get();
>>                      person.surname.set("MySurname"____);
>>                      Property<String> p = person.surname;
>>                      Here, Property is a mutable wrapper around the
>> surname,
>>                      hence the
>>                      get() and set(). Today, this design is only
>>         suitable for the
>>                      client
>>                      side, as creating all the wrapper objects creates
>>         far too
>>                      much garbage
>>                      and churn for a server (tried it, was a car crash).
>>                      However, despite the appeal of making this work via
>>         value
>>                      types, I'm
>>                      willing to agree that allowing mutability would
>>         have far too
>>                      many
>>                      otehr negative consequences. Thus I agree with the
>>         "only
>>                      immutable"
>>                      design direction.
>>                      Stephen

More information about the valhalla-dev mailing list