Aleksey Shipilev wrote:
Hi, Tim!
Thanks for reminder :) Let me explain the situation for DRL VM
performance. There two main points of degradation caused by your
patch:
1. Break of scalar replacement on instanceof operation, solved by HARMONY-5014.
2. Changes in inline tree caused by increased method sizes in HashMap.
Ok, that wasn't clear to me, so thanks for explaining.
This (2) is main concern, the problem is method findNonNullKeyEntry,
which double its size with your change. I had played with inliner
heuristic in OPT, but can't find optimal configuration for it. By
"optimal" I mean configuration that show at least same performance
that original HashMap does. That mean even with HARMONY-5014 onboard
we have a *degradation*.
Today I realize that we can try to split this method in two chunks
(specialized and not specialized) and thus not interfere much with
inliner heuristics, if we can force inliner to leave cold chunk not
inlined. I'm gonna try this approach this week. So, can we revisit
this discussion after additional data is available? It also will be
great to have your version in form of the JIRA with patch against
current state of trunk.
Thanks Aleksey. I have uploaded the current patch to HARMONY-5374.
It would be good to figure out how we can make a single version work
well for both VMs.
Regards,
Tim
