Bugfix/remove classpath

[pollend]

this reverts the changes in: 8befab3

[keturn]

Here's my current take on this:

This is not a build configuration error.

Some things shifted around and now single-player games (in certain dev environments) are running in to the performance problem we identified in multiplayer games in #4154 back in September.

For next steps, I suggest:

• optimize this code querying subtypes in ModuleEnvironmentSandbox and/or gestalt's ModuleClassLoader. There are some preliminary ideas about that written down already.
• update to current gestalt ([Breaking all] Gestalt v7 re-integration.... #4144), and then optimize that stuff, because some of it probably changes with the new version anyway.

In the meantime, the stopgap workaround is:

• don't have a ton of modules subprojects checked out in your workspace. The performance problem climbs sharply with the number of module directories.

[pollend]

I'm just using the branch to see what is different with the configuration. I don't think its a query problems. something is strange where the classloaders take a really long time to load the classes.

[keturn]

yeah, the note I had on that issue that I don't think is subtype-specific is

the other thing in ModuleClassLoader.loadClass I'm suspicious of is that I think a class loader should check to see if the class is already loaded before calling up the chain, as described for https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean)

but I'm not sure ModuleClassLoader checks that first.

I don't yet understand the ModuleClassLoader thing of each classloader having a parent but ModuleClassLoaders also have a baseClassLoader, so I'm really not sure what order things happen in.

[pollend]

yeah, the note I had on that issue that I don't think is subtype-specific is

the other thing in ModuleClassLoader.loadClass I'm suspicious of is that I think a class loader should check to see if the class is already loaded before calling up the chain, as described for https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean)
but I'm not sure ModuleClassLoader checks that first.
I don't yet understand the ModuleClassLoader thing of each classloader having a parent but ModuleClassLoaders also have a baseClassLoader, so I'm really not sure what order things happen in.

AccessController.doPrivileged(new ObtainClassloader(clazz)); seems to be the main bottleneck in the chain. that also calls ModuleSecurityManager in gestalt.

[pollend]

with this branch the classloader isn't chained to another module class loader. What I'm finding is that the ModuleClassloaders are getting chained to each other. Also doesn't help that reflectionutil will test the string class name with all the module loaded classloaders. This is specific to when an objects is de-serialized and we would like to look up the class by a string for its namespace and classname. I don't think we should be doing this for one the "ModuleName:TargetClass" ModuleName should resolve to the classloader for the target module and the TargetClass is what should be used to resolve the actual module.

ModuleClassLoader --> ModuleClassLoader --> ModuleClassLaoder --> BaseClassloader

below is the relevant callstack to look at.

...
org.terasology.persistence.typeHandling.coreTypes.RuntimeDelegatingTypeHandler.findSubtypeWithName(String)
org.terasology.persistence.typeHandling.reflection.ModuleEnvironmentSandbox.findSubTypeOf(String, Class)
org.terasology.reflection.TypeRegistry.load(String)
org.reflections.ReflectionUtils.forName(String, ClassLoader[])
java.lang.ClassLoader.loadClass(String)
org.terasology.module.sandbox.ModuleClassLoader.loadClass(String, boolean)
java.lang.ClassLoader.loadClass(String, boolean)
...

[keturn]

on the security (not performance) impacts of the classpath thing: #4375

[keturn]

why does this show up when running from IntelliJ but not gradle? Likely clue:

gradle is putting the jar files on the classpath, but IntelliJ is giving the classes directory.

It's not wrong to use the directories here. It might help module and asset hot-reloading speed in development and saves a build step. gradle might well do the same thing if the configuration changes a bit.