After looping over thousands times, the binding failed

[tongqingwu]

In the testing java file, add more than 10000 loops, the fake time will change back to real time. So if we use the fake time agent for over hundreds threads and more test cases, it stops working.

[lukepeeler]

This will work with the following JVM options:

-XX:+UnlockDiagnosticVMOptions 
-XX:DisableIntrinsic=_currentTimeMillis 
-XX:CompileCommand=exclude,java/lang/System.currentTimeMillis

[lukepeeler]

This was for Java version:

java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

[arvindsv]

@lukepeeler: Are you saying that the method got jitted and it was replaced with some intrinsic version of System.currentTimeMillis?? Wow. Ok. If so, I might need to find out if there's a way to disable that, for this method, from the agent.

[arvindsv]

I guess, not jitted. But, replaced with a native call, without JNI overhead.

[arvindsv]

Looks like you're right. The C2 compiler has a threshold of 10000 calls.

[lukepeeler]

Yeah, I got it to work initially with just -Xint which disabled JITing entirely but slows everything else down horribly as well.
The last option I listed above just tells the JVM not to JIT compile for this method, but it didn't prevent the mapping to the intrinsic method that the JVM usually associates with it, so I needed the extra option to disable the intrinsic mapping.

[arvindsv]

Ok, thanks!

It gets too hairy to try and do this in JVMTI, in my opinion. So, maybe we should document this?

[arvindsv]

If you agree, and want to make a change in the README, please do so. If you think something else can be done, I'm all ears.

[lukepeeler]

Yeah, I agree. And I think polluting the JVMTI code you have with what really amounts to a special case would make it harder for others to make it reusable for more general cases of binding natives. I think documentation is fine. There's a whole list of native methods that get the intrinsic treatment (though this probably differs by flavor/version of JVM): http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/classfile/vmSymbols.hpp#l581

[arvindsv]

Ok. Makes sense.

@tongqingwu, since you opened the original issue, can you verify that the suggested flags fix the issue for you too? If so, I can update the README.

[arvindsv]

@lukepeeler: Yes, I saw vmSymbols.hpp, when I was seeing if it's easy to disable intrinsics for this method. I was hoping for an easily accessible method to do that. But, it doesn't look like there is one.

[tongqingwu]

@arvindsv : The solutions from Luke @lukepeeler works great! You should update the README.

This is the java version I am testing on, and with over hundreds of threads.

java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

[arvindsv]

Done! I'll close this issue then. Thanks to both of you!