RFR: 8301997: Move method resolution information out of the cpCache [v2]

[Andrew Dinn]

On Wed, 18 Oct 2023 14:57:04 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed some comments and relocated code
>
> src/hotspot/share/oops/cpCache.hpp line 47:
> 
>> 45: 
>> 46: // A constant pool cache is a runtime data structure set aside to a constant pool. The cache
>> 47: // holds interpreter runtime information for all field access and invoke bytecodes. The cache
> 
> The cpCache is not a cache (this name should be changed at some point) and is not interpreter specific.
> The cpCache stores the results of fields and methods resolutions, which are then used by all VM components (interpreter, runtime, JITs).

I think there is a bit more nuance needed here. Strictly, the cpCache *is* a cache since it retains values for re-use that would otherwise need to be recomputed. What it is not is a traditional key-value lookup store i.e. it does not conform to the common usage of 'cache' in computer science parlance but to a more broad use of the term in English. I agree that we could do with a better name.

Also, while you are correct to note that the runtime uses the cpCache during link resolution and that the JITs use the cpCache when generating compiled code, it is also true that the resulting JITted method code does not refer to the cache as part of its operation. So, as far as the execution engine of the JVM is concerned, the info in the cpCache is present to optimize interpreted execution and is incidental to compiled execution. That distinction explains why it has been referred to as an interpreter 'cache' or 'scratch pad' and I think this is worth noting, albeit at the risk of down-playing those other uses. This present discussion may well all that is needed to provide that note so, as you say, the comment should probably avoid tying the cpCache exclusively to the interpreter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15455#discussion_r1365696830