The "internal fixed-size structures" in the Java HotSpot compiler is not related to this message. It is related to the way methods calls and method entries are encoded, with strange limitations on the supported method signatures (the count and types of parameters).

These limits on supported method calls are really not intuitive and they way they can be fixed is opposed to the normal OOB programming philosophy of Java:
- sometimes this requires creating temporary work classes to pass these method parameters.
- sometimes some large methods need to be splitted in the source code by the programmer into smaller sub-methods even if the method size is below the threshold of about 4KB of bytecode.
- some small methods fail when HotSpot try to inline them in the compiled native code, or will run much slower if they are not inlined manually directly in the source code.
- the methods profiling performed by HotSpot to determine which methods should be inlined is based on a threshold number of past calls. But this counting does not work for all calls, so some methods may never reach this threshold, even if they are used extremely often. These small methods are nearly never compiled to native code and run slower.
- more generally, the rationale of these limits is not clear, and one needs to profile the application in its critical code parts to see which coding style will work best.

You can diagnose the cases where methods will not be compiled to native code at run-time by HotSpot (and then will run in a much slower interpreted mode) with some undocumented flags on the "java" command-line or set by the JVM instanciation program (such as limewire.exe on Windows): it displays "COMPILATION SKIPPED" messages on the console.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml