RFR: 8255617: Zero: purge the remaining bytecode interpreter profiling support

[Jie Fu]

On Tue, 3 Nov 2020 07:50:11 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> @DamonFool, @GoeLin, do you have an opinion here?
>
>> @DamonFool, @GoeLin, do you have an opinion here?
> 
> Hi @shipilev ，
> 
> Sorry, I missed this PR before.
> I'll have a look and do some experiments and will let you know soon.
> 
> Thanks.

> > I left this code from the C++ interpreter because I had a dream that we could someday hook zero up to c1/c2 someday, but if so, there would be a more work than adding these back. I'd be interested to see what these other people with interest in Zero think. But this LGTM.
> 
> It is my understanding that Zero had basically stepped back to be the "pure" interpreter without any support for compilers, and thus becoming the most portable thing, for example for architectures that have no arch-specific code implemented whatsoever. When one needs an interpreter that hooks into C1/C2, they have to go to template interpreter and start implementing arch-specific stuff. So, porting is basically: a) get Zero working; b) get template interpreter working; c) get C1 working; d) get C2 working. On each of these steps you have something that works, with every step much harder to get it right, but better for performance.
> 
> So in this sense, having compiler hooks (like this interpreter profile support) penalizes Zero execution for nothing. If we continue it further, I'd say we can also purge deopt support from Zero too.
> 
> Need more thoughts about this, so:
> 
> /reviewers 3

+1

All tests for Zero VM passed in our CI/CD.
And the build time for zero-release vm reduced 20s ~ 30s on our platforms.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/944