Clarification on migration to value types and boxed vs unboxed representations

[Vitaly Davidovich]

The use cases in mind all fall into the "wide" struct case, whether being
wide in breadth (lots of fields) or depth (structs embedding other
structs).  Generally speaking, there are cases where you want to bundle up
a bunch of mutable state (primitives mostly, but can be mix of refs as
well) and then pass that blob around.  In financial markets, there are
entities which carry a good deal of timestamps for example, and some of
those timestamps may be mutated/set by different phases in a processing
pipeline; the terminal phase then processes all of them.  Similarly, in
graphics code, you may have lots of temporaries that are set up in a render
pipeline across different stages before finally being rendered.

As I mentioned, mutable struct cases aren't that frequent but quite useful
to have when needed.  In particular, if the cost of copying the struct
around is more expensive than the operations performed on its data, we're
back to having mechanical overhead exceeding useful work.  In this sense, I
feel that .NET got this part right by providing flexibility and some tools
(e.g. pass by ref) to handle these instances neatly without sacrificing
performance or encapsulation.

Agree that taking away locality by playing indirection games isn't a
worthwhile tradeoff.  It is, however, somewhat unfortunate that java's
version of this concept won't be as powerful (or flexible, if you prefer)
as .NET.  If one could fuse the CLR type system with JVM's runtime (GC,
JIT), I think you'd get one heck of a performant managed runtime; one can
dream! :)

Having said all that, I'll still take immutable value types over the
current bloat/indirection situation, so thanks for taking up this effort.

Sent from my phone
On Jan 5, 2015 10:55 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Jan 5, 2015, at 5:58 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> > What's the plan to avoid such copying costs with proposed value types in
> java?
>
> Value types are designed for small structures of a few words, like complex
> numbers or foreign pointers, not wide aggregates like "struct stat".
>
> If there are enough use cases for wide values, we can reduce copying by
> adding hidden indirections.  But building indirections into the design
> defeats one of our goals, which is memory locality.  Locality is obtained
> by placing a value inside of its containing object or array.  Clever
> bit-sharing indirections, at least for small values, would probably add too
> much overhead.
>
> Value types are not structs, and will be useful for emulating only those C
> structs which are passed by value.
>
> Do you have another use case in mind?
>
> — John