search

arvindsv / faketime

Java agent to enable changing time in a Java project, mainly for testing.
18 stars 12 forks source link

After looping over thousands times, the binding failed #3

Closed tongqingwu closed 7 years ago

tongqingwu commented 7 years ago

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 commented 7 years ago

This will work with the following JVM options:


-XX:+UnlockDiagnosticVMOptions 
-XX:DisableIntrinsic=_currentTimeMillis 
-XX:CompileCommand=exclude,java/lang/System.currentTimeMillis
lukepeeler commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

arvindsv commented 7 years ago

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

lukepeeler commented 7 years ago

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 commented 7 years ago

Ok, thanks!

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

arvindsv commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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