further to Stephen's thoughts on Value Objects

[Vitaly Davidovich]

The problem here would be the added GC pressure from the constant boxjng,
unless fully eliminated by the compiler.

How would you store a pointer to the value object if that thing never had a
heap address? If it's a stack allocated variable then it only lives in
stack memory and/or registers.  Without JVM gymnastics,  you'd have to copy
data into a heap box; locality is fine then but you get GC pressure and
copying cost.

Also, how reliable is it to rely on JVM to always remove the boxing? If
this is predicated on escape analysis, I'd be nervous since it leaves quite
a bit to be desired.

Sent from my phone
On Jan 5, 2015 6:17 PM, "Thomas W" <twhitmore.nz at gmail.com> wrote:

> Hi Stephen, people,
>
> Just one further thought about Value Objects -- Stephen's objection was in
> regard to repeated boxing in/out of API.
>
> > Consider an OSS library released for
> > JDK8 that has a method process(Object). The intent is that the method
> > accepts anything, we don't care what the type is. When used with
> > JDK10/11 it still accepts anything, except that instead of a small,
> > known number of types being boxed (for which the library might have a
> > process(int) overload, there are now *lots* of boxing operations.
>
> I'm not a VM expert, but I understand that locality is the main issue in
> terms of memory performance. Would it be possible for the 'Value Object
> boxes' to just hold a pointer to the original Value Object struct,  to
> retain locality & avoid copying?
>
> This would still incur cost of creating a box, but keep the benefit of
> locality.
>
> I did look at Albert Noll's report on heisenboxing, and it sounds good --
> I'd support formally sidelining or eliminating identity for primitive
> wrappers -- but didn't discuss the implementation details of boxing, only
> unboxing. Quite possibly this has already been considered.
>
>
> Regards,
> Thomas Whitmore
>