Impact of number of classes on JVM performance

[Sampath Herga]

Hi,

For a project, to speed up the performance of a critical path, we are looking at generating code for some computations. The computations generally involve calling some methods and then some boolean expressions on the results of the methods. By generating code we are able to run it much faster as against using something like MVEL for evaluating the expressions. But, the problem is that we end up generating a large number of classes (one for each expression). The number can be more than 100k. Couple of questions here

1. How does the number of classes impact the overall JVM performance. Is there any way to measure this? We can change the generation strategy to generate the expressions as individual methods of classes instead of classes. Would this help?

2. Due to some quirks, the generated classes have to be in a single file. This creates real big files (approx 40MB). Initial load time is very high, but, other than this is there any other impact of big java files?

Thanks,

Sampath

[Vitaly Davidovich]

You're better off generating more methods than classes.  More classes means longer startup time, larger memory footprint, and more GC marking overhead.

Irrespective of method or class generation, keep an eye on your code cache usage; if it's exhausted, compilation will cease and performance will drop off significantly.

Your source java file with multiple classes will generate one class file per class in there, so from runtime performance aspect I don't think it matters.

sent from my phone

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kirk Pepperdine]

I don’t see how more methods vs more classes helps here. Methods also have a cost.

Regards,

Kirk

[Vitaly Davidovich]

They're not free, but think about it: if you generate a class, you still need the method.  So for each method you end up with an enclosing class that's carrying metadata, takes up space in the system dictionary, sits on the class resolution path, is examined for class load dependency checks, etc.  It's a waste if its only reason for existence is to provide a home for one generated method.

But as I mentioned, perf after startup will likely depend on code cache.

sent from my phone

[Ivan Krylov]

Depends on a lifecycle of the generated code. A method can not retire from heap on it's own, the owning class needs to be collected.  So I would cluster methods according to their liveness.

Ivan