RFR: 8309976: Add microbenchmark for stressing code cache [v4]

[Eric Caspole]

> Most benchmarks have a relatively small code footprint compared to enterprise applications. While trying to model an application with a very large code footprint, we developed this JMH with its own classloader generating the desired number of classes from the string literal in the file, using the existing InMemoryJavaCompiler. Then these classes are are instantiated to the desired count, and methods are called in those objects, which can fill up the code cache, possibly causing code cache sweeping or compiler shut-off. 
> This allows to create a simulation of a large application with arbitrary java heap and code cache footprint, and take advantage of the benefits of JMH at the same time.
> The defaults are set very low by default and the intent is that they would be customized for any given study.

Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:

  Cleanups from Alekseys suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14521/files
  - new: https://git.openjdk.org/jdk/pull/14521/files/8fdb3c96..a81f0d4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14521&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14521&range=02-03

  Stats: 25 lines in 1 file changed: 6 ins; 7 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/14521.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14521/head:pull/14521

PR: https://git.openjdk.org/jdk/pull/14521