Chengrong, I think it is vice versa. Wherever you have a safe point, stack must be enumerable.
Fast path does not contain safe points, so no need for m2n there. Slow path contains some - and we have to create m2n to allow stack enumeration if GC happens. Pavel. P.S. BTW, not creating m2n makes fast path even faster. On 12/18/07, 史成荣 <[EMAIL PROTECTED]> wrote: > I am not familiar with the relationship between setting the m2nframe and > GC. > I guess if there is no potential garbage collection, it's better to take > the > fast path,because the fast path does not contain safepoint for GC to > start, > and if GC really happens when a thread is requiring or releasing a lock, > then it should transfer from the fast path to the slow one so that GC > can start, because the slow path contains safepoint for GC to start. And > in order to unwind the stack correctly, the m2nframe should be setted > before > the slow path. > Am I right or I missed some thing else? > > Thanks, > Chengrong > > > 2007/12/18, Xiao-Feng Li <[EMAIL PROTECTED]>: > > > > On Dec 18, 2007 8:43 PM, 史成荣 <[EMAIL PROTECTED]> wrote: > > > why does it need setting the m2nframe before the slow path while it > > needn't > > > when taking the fast path? > > > > As I said below, that's for potential garbage collection or exception > > throwing, when you need unwind the stack correctly. > > > > Thanks, > > xiaofeng > > > > > 在07-12-18，Xiao-Feng Li <[EMAIL PROTECTED]> 写道： > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > -- > > http://xiao-feng.blogspot.com > > > -- Pavel Pervov, Intel Enterprise Solutions Software Division
