Valhalla, startup, performance of interpreter, and vwithfield
karen.kinnear at oracle.com
Mon May 13 13:55:02 UTC 2019
Thank you Sergey - that is very helpful and timely.
> On May 10, 2019, at 7:07 PM, Sergey Kuksenko <sergey.kuksenko at oracle.com> wrote:
> Hi All,
> I did quick evaluation of startup and interpreter performance cost. I have to take back my words that "vwithfield is major contributor to the interpreter speed and merged(or fused) vwithfield could improve interpreter performance". It was quite long time age when I was looking into interpreter's performance last time. I have to say that a huge work was done for interpreter since that time and now I don't consider interpreter's performance as an issue. As for vwithfield, now cost of the single vwithfield (in the interpreter) is approximately 200ns (on 2.2GHz freq). It is not a big nor a small value. If compare cost of value creation vs cost similar classic java object creation (simple writes) then single vwithfield costs ~7%-10% from the whole object creation. So I am guessing that if you have a value with 10 fields (and 10 vwithfield operations) - you may double value creation cost, but it will have minor impact for the whole execution.
> Also I have to say that if look into startup for the first execution of code - interpreter takes less than 1%. All others actions (classloading, verification, etc..) take much more time. As for "time to performance" - I didn't evaluate it yet. Interpreter's impact could be higher in that case. At the same moment - working TieredCompilation will improve "time to performance" much more than any interpreter tuning.
More information about the valhalla-dev