Chengrong, locking is expensive, which should be optimized or avoided. The fast path acquiring the lock without Java-native border crossing can be much fast. It's expected the fast path be executed in most cases. This is possible if the code sequence doesn't trigger garbage collection or exception, hence no need to bookkeeping the frames.
Thanks, xiaofeng On Dec 18, 2007 10:54 AM, 史成荣 <[EMAIL PROTECTED]> wrote: > I found in the process of locking > Java*<file:///E:/project/jit/Harmony/working_vm/vm/thread/doc/ThreadManager.htm#*>monitors, > there is a fast path to acquiring the Java > *<file:///E:/project/jit/Harmony/working_vm/vm/thread/doc/ThreadManager.htm#*>monitor. > In this scenario, the helper does not need to switch between Java > *<file:///E:/project/jit/Harmony/working_vm/vm/thread/doc/ThreadManager.htm#*>and > native frames. Otherwise, the helper code enters a slow path by > switching between > Java*<file:///E:/project/jit/Harmony/working_vm/vm/thread/doc/ThreadManager.htm#*>and > native code. > I do not know why to do this. and what is the difference between > them? Could anyone give some directions? > > Thanks, > Chengrong > -- http://xiao-feng.blogspot.com
