Value types - compatibility with existing “value objects”

Brian Goetz brian.goetz at
Thu Jan 8 16:45:00 UTC 2015

> It also addresses this (I think serious) problem in current proposal:

You say "problem", I say "tradeoff".

>     “Value types” seem to assume that you will use it just for small
>     types and you will implement bigger types as objects (with different
>     syntax).

Essentially, yes.  There's no hard cutoff of "value types must be less 
than X size", but the VM reserves the right to transparently box values 
that are too big (this is better than rejecting them either statically 
or dynamically).  You can still code them as values and get the value 
semantics and the VM will try its best to give you the performance, but 
you don't get guaranteed flattening.  (Note that the benefits of 
flattening decrease dramatically once they get big enough anyway.)

If we could make objects just magically work like ints when they were 
small enough, there'd be no need to introduce a new construct in the 
first place.

>     In practice this might be a problem. E.g. in computer
>     graphics/vision you have vectors of various dimensions (2,3,4),
>     matrices of various dimensions (2x2,2x3,3x3,4x3,4x4) and other
>     similar immutable types. Having different syntax for these based on
>     the size (2x2 matrix of floats is value type, but 4x4 matrix of
>     float or 2x2 matrix of doubles should be object) will be really
>     cumbersome.

I am not sure where you got this idea that somehow "too big" values 
would require a different syntax.  However, its possible you're running 
on a machine with a very restricted register set, and a 4x4 matrix of 
longs is too big to pass by value, so it gets silently boxed, and you 
don't get all the performance you get with a 2x2 matrix.  But this is no 
different from any other hardware effect (size or number of cache lines, 

(And yes, we understand that transform matrices is a desirable thing to 
be able to fit into the sweet spot.)

Will value types solve all indirection-related performance woes? 
Clearly not.  There are some people who would prefer something more like 
mutable structs, which would address a different subset of 
indirection-related performance woes (and introduce a whole new set of 
complexities.)  IBM's Packed Objects proposal had a whole different set 
of tradeoffs.

> On Thu, Jan 8, 2015 at 5:02 PM, Brian Goetz <brian.goetz at
> <mailto:brian.goetz at>> wrote:
>     Like many questions we get here, this is a fine question which has
>     basically arrived at the wrong time, so we're going to ignore it for
>     a while.  Not because it's not important -- it is!  But because you
>     have to pour the foundation before you can paint.  And the
>     foundational work is occupying all of our attention right now.
>     Of course migrating existing value-based classes is a highly
>     desirable thing and it will definitely be on our mind as we work
>     through the more foundational aspects.  String may in the end be a
>     lost cause -- I guarantee you there is plenty of mission-critical
>     code out there that synchronizes on strings -- but there are plenty
>     of value-based classes in the JDK that could benefit from such a
>     treatment and might be less problematic to convert.
>     This is already on the "to think about next year" list, but since
>     the "to think about this year" list is already several years long,
>     we probably won't get to it for a while.
>     On 1/8/2015 9:51 AM, Palo Marton wrote:
>         Yes, I know that you can not simply replace existing value
>         objects with
>         value types when executing old pre-values-types code. Such code
>         must be
>         executed with objects.
>         My idea is something along these lines:
>         Declare value types as normal class (final with final fields),
>         but add
>         secondary "value name" for it, e.g. like this:
>         public final class *String *value *string *{
>         ...
>         }
>         When in your code you declare variable as "String" than it will
>         work the
>         same as it works now (with identity, lock, null, etc..)
>         But when you declare variable as "string", you basically say that:
>         - I don't care about identity and locking and don't plan to use it
>         - this will never be null.
>         Which gives JVM option to store and pass it "by value" instead
>         of "by
>         reference".
>         On Thu, Jan 8, 2015 at 3:24 PM, Vitaly Davidovich
>         <vitalyd at <mailto:vitalyd at>> wrote:
>             I don't think this has been ignored, certainly not on the
>             recent traffic
>             on this mailing list.
>             I think the short answer to the "can existing classes that
>             are value
>             objects be migrated to value types with no client change" is
>             probably no.
>             The reason, or one of them, is that there's no way to know
>             (without
>             analyzing all usages) whether client code uses object
>             features of said
>             object (e.g. uses reference identity comparison, locks on an
>             instance, etc).
>             In your rephrasing, "works like a class" implies identity of
>             the object
>             and can be synchronized on.  That's not what VT is of course.
>             Sent from my phone
>             On Jan 8, 2015 9:17 AM, "Palo Marton" <palo.marton at
>             <mailto:palo.marton at>> wrote:
>                 My question is not just about String but about all
>                 existing value types.
>                 There are many of them in current java code (both JDK
>                 and user code).
>                 Current proposal seems to ignore them.
>                 I think that the original idea of VT:
>                 "Codes like a class, works like an int!"
>                 can be changed to:
>                 "Codes like a class, works like class, but can be stored
>                 and passed as
>                 int!"
>                 as the problem with current value objects (like String)
>                 is not with the
>                 fact that they are objects, but in how they are stored
>                 in memory and passed
>                 between functions.
>                 On Thu, Jan 8, 2015 at 3:02 PM, Vitaly Davidovich
>                 <vitalyd at <mailto:vitalyd at>>
>                 wrote:
>                     I had a suspicion this would be the gist.  However,
>                     I think better
>                     solution is to simply change string to have inline
>                     storage of the data, so
>                     no indirection to the char[].  Ultimately, the
>                     string data will have to
>                     live on the heap one way or another,  but it'd be
>                     nice if String had that
>                     data inlined into its storage so when you load
>                     address of string you get
>                     the data at a small fixed offset from that address.
>                     Sent from my phone
>                     On Jan 8, 2015 8:54 AM, "Peter Levart"
>                     <peter.levart at
>                     <mailto:peter.levart at>> wrote:
>                         On 01/08/2015 02:50 PM, Vitaly Davidovich wrote:
>                             Why do you want string to be value type?
>                             What problem (s) will that
>                             address?
>                         String as a value type would eliminate one
>                         indirection. If would
>                         effectively become an immutable char[] with a
>                         bunch of operations.
>                         Peter
>                             Sent from my phone
>                             On Jan 8, 2015 7:04 AM, "Palo Marton"
>                             <palo.marton at
>                             <mailto:palo.marton at>> wrote:
>                                Thank you for response. I have read that
>                             thread. But apart from first
>                                 few
>                                 messages it seems to deal with something
>                                 else - mutable types.
>                                 My idea with rewriting String as value
>                                 is not about changing meaning
>                                 of
>                                 java.lang.String. That identifier should
>                                 still mean heap object with
>                                 identity, null, etc... The idea is to
>                                 give a new name for string
>                                 value,
>                                 e.g. java.lang.string (lowercase s), or
>                                 just "string". So "String"
>                                 will be
>                                 boxed version of "string" and all old
>                                 pre-value-types code will use
>                                 only
>                                 boxed objects as before and there will
>                                 be no semantic change. In new
>                                 code
>                                 you will use "string" in most cases, but
>                                 you can use also "String" in
>                                 places where you need it.
>                                    From what I have read there are no
>                                 plans to support something like
>                                 that. Am
>                                 I right?
>                                 Reason why I am asking this is that some
>                                 time ago I was thinking about
>                                 value types in java and how they should
>                                 be implemented in JVM. My idea
>                                 about how to implement it in JVM was
>                                 somehow different, but it can
>                                 support
>                                 this old-code / new-code compatibility.
>                                 On Thu, Jan 8, 2015 at 11:42 AM, Richard
>                                 Warburton <
>                                 richard.warburton at
>                                 <mailto:richard.warburton at>> wrote:
>                                    Hi,
>                                     Will it be possible (within
>                                     valhalla) to rewrite java String as
>                                     value
>                                 type
>                                     in JDK and use it in all places in
>                                     JDK where it makes sense? (eg.
>                                         Class.forName(string),
>                                         Object.toString(),
>                                         Integer.parseInt(string).
>                                         …)
>                                         Or more general question:
>                                         There are already plenty of
>                                         “value objects” in existing java
>                                         code.
>                                         In
>                                     JDK
>                                     we have, String, File, Point2D,...
>                                     Also many people have already
>                                     declared
>                                     their own class Point { final x,y; }
>                                     and similar objects. Once we
>                                         move
>                                     to
>                                     value types in java, will it be
>                                     possible to rewrite these to value
>                                         types
>                                         without breaking compatibility
>                                         with old pre-value-types code? E.g.
>                                         if I
>                                         change my Point object to value
>                                         type in my library, can this new
>                                         library
>                                         (jar) still be used in other
>                                         projects that were written
>                                         before this
>                                         change?
>                                         And without need to recompile
>                                         those other projects?
>                                     See this thread:
>                                     <>
>                                 January/000546.html
>                                     regards,
>                                          Richard Warburton
>                                          @RichardWarburto
>                                     < <>>

More information about the valhalla-dev mailing list