Civilizer - let's civilize those primitive types !

[Red IO]

This sounds really similar to c++ return value optimizations.
Of cause it makes sense to not unnecessarily move the return value out of
register before returning from the function only to load it back in, in the
action directly after the end of the returning function.

On Fri, Jan 13, 2023, 16:34 Brian Goetz <brian.goetz at oracle.com> wrote:

> > I didn't think about registers at all while underestimating the depth of
> optimization the runtime can do. I wasn't expecting the vm to intelligently
> manage registers at runtime.
> >
> > But I doubt that value objects will be often only stored in registers
> since their space is (on most platforms) pretty limited. You would need to
> strip unused fields from the object which often will reduce the object to
> maybe 1-2 int or something, reducing it to nothing more than the arguments
> for the next cpu cycle. But storing a larger object > ~200 bytes completely
> in registers is impossible in the first place. And storing multiple value
> objects simultaneously in registers is even more unlikely to happen.
>
>
> It is easy to think about Valhalla as being about “blocks and pointers”,
> and see the main benefit as eliminating some of those pointers by inlining
> layout into enclosing blocks.  And indeed, that is one of the benefits of
> Valhalla, and the easiest to visualize from a C-centric viewpoint.  But,
> that’s only part of the story.  If you have a value type Point, and you
> return a Point from a method, the calling convention for the method will
> routinely pass the Point fields in registers.   And in many cases, where a
> value is used only to communicate an aggregate between a caller and a
> callee, the value need never hit memory at all.  This is a significant part
> of what Valhalla is providing.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230114/8dd2dea5/attachment.htm>