gn_164 wrote:I don't know the details of the actual patch but it is probably occurring because you are using reflection and the reflection inflation mechanism is kicking in. With reflection initially native code is used to perform method/constructor calls, however this is slower than executing the equivalent bytecode. So there is an inflation mechanism whereby after a certain threshold of calls to a given method/constructor is reached, the native accessor is replaced with a generated accessor - which is in effect a class written just to perform the requested invocation. That class is dynamically loaded and then subject to JIT compilation like a normal class. Consequently, this process can introduce significant jitter effects:
After looking up the file I found that the most propable cause of the jitter is the:
"patching call, RealtimeThread-5, invokespecial at bci 43 in method virtual jobject sun.reflect.GeneratedMethodAccessor65.invoke(jobject, jobject) for method virtual void java.lang.Boolean.<init>(jboolean)"
Any idea why this is happening? What exactly is the patching call?What about the invokespecial?
If I am understanding it correctly patching is happening because my class loading and initialization code kicks in only after RTJ is done with precompiling.
java/lang/String java/lang/String java/lang/Object java/lang/System java/lang/Math java/lang/Number java/util/AbstractCollection java/lang/Error java/lang/Double java/lang/Thread java/util/HashMap java/lang/ref/Reference java/io/InputStream sun/misc/Unsafe java/lang/Long java/lang/StringBuffer java/lang/AbstractStringBuilder java/lang/Integer java/lang/Character java/lang/Boolean java/lang/ThreadLocal java/lang/StringBuilder java/lang/Enum java/lang/Integer$IntegerCache java/util/HashMap$Entry sun/nio/cs/ISO_8859_1$Encoder java/nio/ByteBuffer java/nio/Buffer java/nio/CharBuffer java/nio/charset/CoderResult sun/nio/cs/Surrogate$Parser java/io/File java/lang/NullPointerException java/lang/IllegalMonitorStateException sun/net/www/ParseUtil java/util/BitSet java/util/Locale java/lang/CharacterDataLatin1 java/util/ArrayList java/lang/ThreadLocal$ThreadLocalMap java/lang/ThreadLocal$ThreadLocalMap$Entry java/util/concurrent/locks/ReentrantLock java/util/concurrent/locks/ReentrantLock$NonfairSync java/util/concurrent/locks/ReentrantLock$Sync
Prashant-Goel wrote:I don't see anything obvious that would cause an issue. Did the ExceptionInInitializerError report the underlying exception?
I guess it is following class java/nio/charset/CoderResult, Classes in my itc.preinit are in following order
If I am understanding it correctly patching is happening because my class loading and initialization code kicks in only after RTJ is done with precompiling.Patching occurs for a number of reasons. One reason is that when class A is compiled and makes a call to Class B but Class B has not been loaded, then code is generated that has to be patched later, when the code is used, when B has been loaded (or would be forced to load). So you need to load all your classes first and then commence initialization, which in turn performs initialization-time-compilation.
davidholmes wrote:No VM exits with following message
I don't see anything obvious that would cause an issue. Did the ExceptionInInitializerError report the underlying exception?
Patching occurs for a number of reasons. One reason is that when class A is compiled and makes a call to Class B but Class B has not been loaded, then code is generated that has to be patched later, when the code is used, when B has been loaded (or would be forced to load). So you need to load all your classes first and then commence initialization, which in turn performs initialization-time-compilation.I am doing following steps
Prashant-Goel wrote:The alternative is to use java_g and set -XX:+TraceExceptions. That will be a bit "noisy" but will show what exception leads to the ExceptionInInitializerError.
No VM exits with following message
Error occurred during initialization of VM java.lang.ExceptionInInitializerErrorAh I see - that's not very informative, I'll file a RFE to see if we can fix that.
I am doing following stepsStep 1: Generate the initial compilation list
Step 1 : Run my code with -XX:+RTSJBuildCompilationList
Step 2 : Run my code again with -XX:+RTSJBuildCompilationList -Drtsj.precompile=nhrt.precompile
Change code to add the nhrt.precompile file into the application jar, remove -XX:+RTSJBuildCompilationList -Drtsj.precompile=nhrt.precompile,
Mark methods in nhrt.precompile using com.sun.rtsjx.Compiler class for compilation during initialization.
Class.forName(classname, false, null) for all classes in classpath,
Class.forName(classname, true, null)
Step 3 : Run code again without any VM argument for class loading or initializing.
I am still seeing jitter of around 40-50 ms. Am I doing anything in wrong order.It's not clear to me that what you are doing creates a complete compilation list, that covers all the code accessed by RTTs. The usual process here is as follows:
Step 2: Expand compilation list using code-coverage
java -XX:+RTSJBuildCompilationList <app> <args>
Step 3: Based on the compilation list generate the list of classes that need pre-loading & initializing
java -XX:+RTSJBuildCompilationList -Drtsj.precompile=nhrt.precompile <app> <newargs>
Step 4: Use both sets of lists to run the application
java -XX:+RTSJBuildClassInitializationList -Drtsj.precompile=nhrt.precompile <app> <args>
Also you should be able to take your preinit list that causes the ExceptionInInitializerError and simply delete CoderResult from it. That class will be initialized during VM initialization anyway.
java -Drtsj.precompile=nhrt.precompile -Drtsj.preinit=itc.preinit <app> <args>