Repeated creation of type systems can exhaust JVM metaspace

[reckart]

Describe the bug
When repeatedly creating type system instances with lots of classes on a Java 17+ system, it appears that the JVM class metaspace can be exhausted.

To Reproduce
Steps to reproduce the behavior:

1. Create a large type system description
2. Repeatedly create type systems from that description
3. Monitor class metaspace

Diagnosis so far: it appears that TypeSystemImpl.computeAdjustedFeatureOffsets() will always initialize the type2jcci map of the TypeSystemImpl instance. As part of this, FSClassRegistry.createJCasClassInfo() is repeatedly called which creates new generator callsites (lambdas) that start clogging up the metaspace.

The problem happens in particular if CASes are created using a ResourceManager with a custom extension classpath.

  @Test
  void provokeMetaspaceExhaustion() throws Exception {
    tsd.addType(Sentence._TypeName, "", CAS.TYPE_NAME_ANNOTATION);

    for (int i = 0; i < 100_000_000l; i++) {
      var resMgr = new ResourceManager_impl();
      resMgr.setExtensionClassPath(".", false);
      createCas(tsd, null, null, null, resMgr).getJCas();
      // To make sure the consolidated type system is evicted from the weak hashmap cache
      // Alternatively disable type system consolidation
      System.gc(); 
    }
  }

Expected behavior
A solution might be to use the global JCCI cache maintained in FSClassRegistry when populating the TypeSystemImpl.type2jcci maps to avoid repeatedly creating the generator lambdas.

Please complete the following information:

• Version: 3.5.0

References

• JEP 371 introduces the concept of hidden classes and defines their relation to classloaders and loading/unloading
• It seems this may be related to JDK-8302154 - before Java 15 apparently these callsites could be easily garbage collected and now this is more difficult.