valhalla/valhalla/hotspot: multiple value return caused interpreter performance regression

Karen Kinnear karen.kinnear at
Fri Jun 9 15:15:26 UTC 2017

I agree with Roland on pushing Frederic’s changes before considering the vreturn improvements
(I think it is waiting on a code review?) 

My perspective on interpreter performance:
    We do not expect the interpreter implementation in MVT to give significant performance
benefits for value types over references. Our goal has been to try to break even and minimize
performance loss.

    In general for hotspot, our guidance on interpreter performance has been to look
at it in two contexts
         1) general throughput when run with a JIT
         2) startup impact, since it runs prior to the JIT

i.e. performance numbers for -Xint alone are not sufficient to drive decisions.

I haven’t seen the results
    Sergey - do you have a wiki page with test results for MVT or a way to share intermediate
    performance information for specific changes? (delighted you are testing our optimizations!)

> On Jun 9, 2017, at 6:54 AM, Roland Westrelin <rwestrel at> wrote:
> Hi Sergey,
>> I've just realized that this patch causes more than 3x time interpreter 
>> performance regression (if method contains local variable of value type).
>> Question to all: How big INTERPRETER performance regression will be 
>> considered as OK?
> Thanks for the performance number. My change adds 2 runtime calls on
> method returns with a value type from interpreted callee to interpreted
> caller so a big performance drop is not surprising.
> My understanding is that we don't care too much about interpreter
> performance at this point. In any case, I would rather wait for
> Frederic's buffering change to be pushed before considering any
> improvement to the vreturn implementation.
> Roland.

More information about the valhalla-dev mailing list