FWD » Core Development » Database

Email discussion w/ Constantin regarding the custom class loader needed for this implementation:¶

Eric,

Another thought about class loaders: we can create a P2JClassLoader which, depending on some directory configuration, it delegates the work to the MultiClassLoader or to the new DynamicClassLoader (or some other loader, if in the future is found needed), before delegating it to the parent class loader. This way we can always set P2JClassLoader as the system class loader, and enable certain custom loaders as needed, without having to worry if a new loader needs to be integrated/reworked/etc.

Thanks,
Constantin

On 16.04.2015 11:22, Constantin Asofiei wrote:

Eric,

However, the more I've researched the way class loader chaining has to work in order for Hibernate to find the classes with Class.forName(String), it doesn't look like this is feasible, because it seems my class loader has to be the parent of the class loader used to load the P2J and Hibernate classes.

Yes, if not found in the ClassLoader used to load the current class (i.e. a Hibernate class), it delegates the search to the parent class loader, and so on, until the class is found or ClassNotFoundException is thrown. So your new class loader should be the parent of MultiClassLoader (or otherwise, specified as the system class loader).

This means my class loader would have to stay around for the life of the server, and with it many dynamic DMO classes which will no longer be needed.

Yes, the class loader needs to stay alive, but the classes referenced by it can be discarded. As I understand, the reference chaining goes:

class loader <-> class <- objects <- object references

so as long as the chain remains "class <- objects" (as in, the class is removed from the class loader and all its objects are no longer referenced), the garbage collector should be able to pick it up and discard it, together with all its objects. I think this can be proved using MultiClassLoader: have a long enough loop which loads a jar via addJarLoader and a class from that file, creates instance(s) of that class, discards the instance(s), discards the jar via removeJarLoader. If a OOME is not encountered and the heap/permgen get garbage collected, then this proves that discarding the class from the class loader will remove it from the permgen, too.

I've found some interesting details about class loader issues here: http://www.dynatrace.com/en/javabook/class-loader-issues.html

Thanks,
Constantin

On 16.04.2015 10:54, Eric Faulhaber wrote:

Constantin,

Thanks for the reply.

I was hoping to use multiple instances of my class loader, to allow garbage collecting these classes by releasing the loader when the classes were no longer in use (and after they aged out of a cache).

However, the more I've researched the way class loader chaining has to work in order for Hibernate to find the classes with Class.forName(String), it doesn't look like this is feasible, because it seems my class loader has to be the parent of the class loader used to load the P2J and Hibernate classes. This means my class loader would have to stay around for the life of the server, and with it many dynamic DMO classes which will no longer be needed.

Are you aware of any reasonable strategy to allow short-lived classes to be garbage collected granularly?

Thanks,
Eric

On 04/16/2015 03:31 AM, Constantin Asofiei wrote:

Eric,

I'm not aware of any other usage of InMemoryClassLoader expect what was done for the runtime compilation of queries + DMOs. So I think it can be removed from the MultiClassLoader chaining.

Thanks,
Constantin

On 16.04.2015 09:54, Eric Faulhaber wrote:

Constantin,

Do we have any P2J dependency on InMemoryCompiler and InMemoryClassLoader for anything outside of the persist package (other than InMemoryClassLoader being in the chain of class loaders defined by MultiClassLoader)? I couldn't find anything else, but I don't know if there is anything subtle I'm missing, perhaps specific to Majic? I know the test harness uses InMemoryCompiler, but I'm not aware of any dependency back to P2J for that use.

We've already removed the runtime compilation of dynamic queries, and now I'm rewriting the code which compiles dynamically defined temp-tables to generate the DMO interface and implementation class bytecode directly. I want to know how much freedom I have to rework the class loader hierarchy. I am not planning on touching MultiClassLoader, other than to restructure the parent chaining.

Right now, Hibernate is unable to find my classes, since my class loader is outside the chain. I didn't have this problem with my proxy implementation, because I controlled the loading of those classes. However, Hibernate uses Class.forName(String) to retrieve the DMO classes, so I have to do more work to let it find them.

Thanks,
Eric