Clarification on migration to value types and boxed vs unboxed representations
Brian Goetz
brian.goetz at oracle.com
Tue Jan 6 17:26:29 UTC 2015
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