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

[Severin Gehwolf]

On Fri, 30 Oct 2020 13:20:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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.
>
>> 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 backed off to be the "pure" interpreter without any support for compilers, and thus the most portable thing, for example for architectures that have no compiler ports whatsoever. Template interpreter seems to be the thing that hooks up in C1/C2. So, porting is basically: a) get Zero buildable and executable, work out class library problems; b) get template interpreter working; c) get C1 working; d) get C2 working. 
> 
> So in this sense, getting compiler hooks (like this interpreter profile support) penalizes Zero execution for nothing. If that continues, I'd say we can also purge deopt support from Zero. 
> 
> Need more thoughts about this, so:

IIRC the original idea of Zero's compiler support was for shark (via LLVM). That got removed with [JDK-8171853](https://bugs.openjdk.java.net/browse/JDK-8171853). It seems fine to remove profiling support too. So what @shipilev said above makes sense to me. Zero is mostly a porter's tool. Keeping it as simple as possible seems the better approach. +1

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

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