Clarification on migration to value types and boxed vs unboxed representations
Michael Barker
mikeb01 at gmail.com
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 (http://www.objectlayout.org/) - 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 (
https://groups.google.com/forum/#!forum/mechanical-sympathy). Gil and
Martin regularly follow that list.
Mike.
On 7 January 2015 at 06:26, Brian Goetz <brian.goetz at oracle.com> 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 oracle.com
>> <mailto:brian.goetz at oracle.com>> 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 oracle.com <mailto:brian.goetz at oracle.com>
>> <mailto:brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com>__>> wrote:
>>
>> The C# folks concluded in hindsight that mutable structs
>> was a big
>> mistake. See Eric Lippert's blog:
>>
>> http://blogs.msdn.com/b/____ericlippert/archive/2011/03/__
>> __14/to-box-or-not-to-box-that-____is-the-question.aspx
>> <http://blogs.msdn.com/b/__ericlippert/archive/2011/03/__
>> 14/to-box-or-not-to-box-that-__is-the-question.aspx>
>>
>> <http://blogs.msdn.com/b/__ericlippert/archive/2011/03/__
>> 14/to-box-or-not-to-box-that-__is-the-question.aspx
>> <http://blogs.msdn.com/b/ericlippert/archive/2011/03/
>> 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 joda.org <mailto:scolebourne at joda.org>
>> <mailto:scolebourne at joda.org <mailto:scolebourne at joda.org>>>
>> wrote:
>>
>> On 6 January 2015 at 01:58, Vitaly Davidovich
>> <vitalyd at gmail.com <mailto:vitalyd at gmail.com>
>> <mailto:vitalyd at gmail.com <mailto:vitalyd at gmail.com>>> 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