On 2/12/20 5:37 AM, Niranjan Babu Bommu wrote:
have you turned on codecahe , if that is true can you monitor codecahe?
known issue with codecache in java 7, when codecache fills up the compiler
may not get get restarted even after the codecache occupancy drops down to
half after the emergency flushing, this may cause high cpu usage by the
compiler threads.

I've never heard of "codecache"; what is it?

If memory serves correctly, on all AS/400 JVMs (from the very beginning of Java on the AS/400), the first time any Java class or JAR is executed, the Java bytecode gets internally compiled into native code (that's not visible to the user, but which somehow remains persistently attached).

This is somewhat analogous to how non-Java programs work on the AS/400: the program gets compiled to a pseudo-assembler level called "MI," and then goes through a second compilation, called "encapsulation," that takes it down to a level the processor actually executes. So long as the MI level remains present, AS/400 programs will automatically re-encapsulate when moved to a system with a different physical processor; that's why, a quarter of a century ago, you could take AS/400 programs that were compiled on component-CPU boxes (e.g. models like D02, F20, or 200), install them on PowerPC-based boxes (e.g., models like 40s, 170, or 270), and they would port themselves to the new processor.


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to