Increased JIT CPU consumption with JITServer

[mpirvu]

I have spotted a significant (~38%) increase in the CPU consumed by the JIT compilation threads at the client (when connecting to a JITServer). The number of messages exchanged between client and server has also increased substantially. I determined that this increase is mostly due to two messages, ClassEnv_iTableOf and ClassEnv_iTableNext which now account for 37% of all messages exchanged (used to be 0%). These messages appeared as a consequence of PR #22216 and I verified that defining the env var TR_DisableITableIterationsAfterLastITableCacheCheck those messages no longer appear.
I will think of a way of eliminating or at least reducing the number of those messages.

[mpirvu]

One solution could be to let the client count the number of interfaces implemented by a class. The implementation of the frontend query:

uint32_t
TR_J9VMBase::numInterfacesImplemented(J9Class *clazz)
   {
   uint32_t count=0;
   J9ITable *element = TR::Compiler->cls.iTableOf(convertClassPtrToClassOffset(clazz));
   while (element != NULL)
      {
      count++;
      element = TR::Compiler->cls.iTableNext(element);
      }
   return count;
   }

could be overridden at the server to send a message at the client which calls the base class fe()->numInterfacesImplemented(clazz) and returns the number of implemented interfaces to the server.
Given the original distribution of messages:

#0178   32942           ClassEnv_iTableOf
#0179  116634           ClassEnv_iTableNext

this solution would eliminate 116634 messages, but still use 32942 "VM_numInterfacesImplemented" messages.

[mpirvu]

Another solution could be to batch several numInterfacesImplemented() queries into a single query.
This is the original code in codegen:

            for (int32_t i = 0; i < numImplementers; ++i)
               {
               TR_OpaqueClassBlock *containingClass = implArray[i]->containingClass();
               uint32_t numInterfaces = fej9->numInterfacesImplemented((J9Class *)containingClass);
               maxInterfaces = (numInterfaces > maxInterfaces) ? numInterfaces : maxInterfaces;
               }

In this case the server would send to the client a vector of classes, the client would call numInterfacesImplemented() for each of the classes and return the max value needed by the JIT at the server.
For reference, for AcmeAir, the average number of implementers of an interface is 7.

[mpirvu]

Another potential solution is for the server to remember the number of interfaces implemented for each RAMClass it caches. This Information needs to be invalidated when a new interface is introduced into the system. Alternatively, when CHTable modifications are passed from the client to the server, we can update or count of implemented interfaces.