You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by 史成荣 <ic...@gmail.com> on 2007/12/14 08:57:30 UTC
[drlvm][jitrino]
As we know, the key word of "synchronized" in Java will translated into
monenter/monexit pair. And synchronization shoud contain two functions, One
is the mutex lock and the other is the *memory barrier*. I traced the
compiling pipeline from Java bytecode to LIR, found the monenter/monexit
pair is finally transformed into some assembly codes among
which there are codes to call the interface function provided by Thread
Manager. But I didn't find any function provided by Thread Manager
implementing the *memory barrier.* It seams that only the mutex lock is
implemented.
I don't know if I am right. Can anyone give some suggestions?
Thanks,
Chengrong
Re: [drlvm][jitrino]
Posted by 史成荣 <ic...@gmail.com>.
在07-12-15，Xiao-Feng Li <xi...@gmail.com> 写道：
>
> On Dec 15, 2007 2:33 PM, 史成荣 <ic...@gmail.com> wrote:
> > I still have 2 questions.
> >
> > First, I know in the Thread Manager, it is the
> > hythread_thin_monitor_try_enter method to aquire the mutex lock
> > and implement the *memory barrier.* But* *I looked into the code of this
> > method, didn't find any memory barrier operations(including the
> > apr_memory_rw_barrier() call and cmpxchg operation) when it is the fat
> > lock. when aquiring the fat lock, it calls the
> hythread_monitor_try_enter
> > method. In the hythread_monitor_try_enter method* there isn't *memory
> > barrier operations, but has a call of the *hymutex_trylock* method. Does
> the
> > hymutex_trylock method also has barrier effect built-in?
> >
> > Second, when exit the synchoronized area, it should release the mutex
> lock
> > and flush the local memory to the main memory. But the
> > hythread_thin_monitor_exit method only release the mutex lock and I
> don't
> > find any flushing operation in hythread_thin_monitor_exit method.
>
>
> Chengrong, you have good questions. Your questions are related to
> processor memory model, or how to map Java memory model to the
> processor. For example, if the processor has sequential consistency,
> there is no need for any extra flushing operation because all the
> local memory operations enter the system memory hierarchy in order of
> issuing. X86 processors use "processor consistency" which is weaker
> than sequential consistency, so it has xfence instructions for the
> purpose.
>
> So to really understand the issues, you probably can read some
> materials on processor architecture, esp. the memory model part. There
> are chapters in "Computer architecture, a quantitative approach" or
> "Parallel architecture: a hardware/software interface". For a specific
> processor type, you can read its architecture manual to understand its
> behavior in SMP configuration. For example, "lock" prefix in X86
> processor has both barrier and flushing effects.
Do you mean it is OK that there is no flushing operation when exiting the
synchronized area? Or I missed the flushing opertions?
Thanks,
> xiaofeng
> >
> > I think there must be some mistakes of my idea, hoping for your advice.
> >
> >
> >
> > > Thanks,
> > > Chengrong
> > >
> > >
> > >
> > >
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: [drlvm][jitrino]
Posted by Xiao-Feng Li <xi...@gmail.com>.
On Dec 15, 2007 2:33 PM, 史成荣 <ic...@gmail.com> wrote:
> I still have 2 questions.
>
> First, I know in the Thread Manager, it is the
> hythread_thin_monitor_try_enter method to aquire the mutex lock
> and implement the *memory barrier.* But* *I looked into the code of this
> method, didn't find any memory barrier operations(including the
> apr_memory_rw_barrier() call and cmpxchg operation) when it is the fat
> lock. when aquiring the fat lock, it calls the hythread_monitor_try_enter
> method. In the hythread_monitor_try_enter method* there isn't *memory
> barrier operations, but has a call of the *hymutex_trylock* method. Does the
> hymutex_trylock method also has barrier effect built-in?
>
> Second, when exit the synchoronized area, it should release the mutex lock
> and flush the local memory to the main memory. But the
> hythread_thin_monitor_exit method only release the mutex lock and I don't
> find any flushing operation in hythread_thin_monitor_exit method.
Chengrong, you have good questions. Your questions are related to
processor memory model, or how to map Java memory model to the
processor. For example, if the processor has sequential consistency,
there is no need for any extra flushing operation because all the
local memory operations enter the system memory hierarchy in order of
issuing. X86 processors use "processor consistency" which is weaker
than sequential consistency, so it has xfence instructions for the
purpose.
So to really understand the issues, you probably can read some
materials on processor architecture, esp. the memory model part. There
are chapters in "Computer architecture, a quantitative approach" or
"Parallel architecture: a hardware/software interface". For a specific
processor type, you can read its architecture manual to understand its
behavior in SMP configuration. For example, "lock" prefix in X86
processor has both barrier and flushing effects.
Thanks,
xiaofeng
>
> I think there must be some mistakes of my idea, hoping for your advice.
>
>
>
> > Thanks,
> > Chengrong
> >
> >
> >
> >
>
--
http://xiao-feng.blogspot.com
Re: [drlvm][jitrino]
Posted by 史成荣 <ic...@gmail.com>.
I have known what to do. thank you!
Re: [drlvm][jitrino]
Posted by Gregory Shimansky <gs...@apache.org>.
On 15 декабря 2007 史成荣 wrote:
> 2007/12/15, Gregory Shimansky <gs...@apache.org>:
> > On 15 December 2007 史成荣 wrote:
> > > I still have 2 questions.
> > >
> > > First, I know in the Thread Manager, it is the
> > > hythread_thin_monitor_try_enter method to aquire the mutex lock
> > > and implement the *memory barrier.* But* *I looked into the code of
> > > this method, didn't find any memory barrier operations(including the
> > > apr_memory_rw_barrier() call and cmpxchg operation) when it is the fat
> > > lock. when aquiring the fat lock, it calls the
> >
> > hythread_monitor_try_enter
> >
> > > method. In the hythread_monitor_try_enter method* there isn't *memory
> > > barrier operations, but has a call of the *hymutex_trylock* method.
> > > Does the hymutex_trylock method also has barrier effect built-in?
> >
> > Fat monitors use OS synchronization primitives. You can take a look in
> > vm/thread/src/{win,linux}/os_mutex.c files to see the exact
> > implementation.
>
> I had taken a look into vm/thread/src/{win,linux}/os_mutex.c files, and
> found pthread_mutex_trylock(linux) and TryEnterCriticalSection(win)
> methods. Do you mean the two methods not only have mutex lock function, but
> also have barrier effect?
They do all (you can be sure about it) of the necessary synchronization stuff
since they go into the OS kernel. In case the processor architecture needs
memory barriers they do it.
--
Gregory
Re: [drlvm][jitrino]
Posted by 史成荣 <ic...@gmail.com>.
2007/12/15, Gregory Shimansky <gs...@apache.org>:
>
> On 15 December 2007 史成荣 wrote:
> > I still have 2 questions.
> >
> > First, I know in the Thread Manager, it is the
> > hythread_thin_monitor_try_enter method to aquire the mutex lock
> > and implement the *memory barrier.* But* *I looked into the code of this
> > method, didn't find any memory barrier operations(including the
> > apr_memory_rw_barrier() call and cmpxchg operation) when it is the fat
> > lock. when aquiring the fat lock, it calls the
> hythread_monitor_try_enter
> > method. In the hythread_monitor_try_enter method* there isn't *memory
> > barrier operations, but has a call of the *hymutex_trylock* method. Does
> > the hymutex_trylock method also has barrier effect built-in?
>
> Fat monitors use OS synchronization primitives. You can take a look in
> vm/thread/src/{win,linux}/os_mutex.c files to see the exact
> implementation.
I had taken a look into vm/thread/src/{win,linux}/os_mutex.c files, and
found pthread_mutex_trylock(linux) and TryEnterCriticalSection(win) methods.
Do you mean the two methods not only have mutex lock function, but also have
barrier effect?
> > Second, when exit the synchoronized area, it should release the mutex
> lock
> > and flush the local memory to the main memory. But the
> > hythread_thin_monitor_exit method only release the mutex lock and I
> don't
> > find any flushing operation in hythread_thin_monitor_exit method.
> >
> > I think there must be some mistakes of my idea, hoping for your advice.
>
> --
> Gregory
>
Re: [drlvm][jitrino]
Posted by Gregory Shimansky <gs...@apache.org>.
On 15 December 2007 史成荣 wrote:
> I still have 2 questions.
>
> First, I know in the Thread Manager, it is the
> hythread_thin_monitor_try_enter method to aquire the mutex lock
> and implement the *memory barrier.* But* *I looked into the code of this
> method, didn't find any memory barrier operations(including the
> apr_memory_rw_barrier() call and cmpxchg operation) when it is the fat
> lock. when aquiring the fat lock, it calls the hythread_monitor_try_enter
> method. In the hythread_monitor_try_enter method* there isn't *memory
> barrier operations, but has a call of the *hymutex_trylock* method. Does
> the hymutex_trylock method also has barrier effect built-in?
Fat monitors use OS synchronization primitives. You can take a look in
vm/thread/src/{win,linux}/os_mutex.c files to see the exact implementation.
> Second, when exit the synchoronized area, it should release the mutex lock
> and flush the local memory to the main memory. But the
> hythread_thin_monitor_exit method only release the mutex lock and I don't
> find any flushing operation in hythread_thin_monitor_exit method.
>
> I think there must be some mistakes of my idea, hoping for your advice.
--
Gregory
Re: [drlvm][jitrino]
Posted by 史成荣 <ic...@gmail.com>.
I still have 2 questions.
First, I know in the Thread Manager, it is the
hythread_thin_monitor_try_enter method to aquire the mutex lock
and implement the *memory barrier.* But* *I looked into the code of this
method, didn't find any memory barrier operations(including the
apr_memory_rw_barrier() call and cmpxchg operation) when it is the fat
lock. when aquiring the fat lock, it calls the hythread_monitor_try_enter
method. In the hythread_monitor_try_enter method* there isn't *memory
barrier operations, but has a call of the *hymutex_trylock* method. Does the
hymutex_trylock method also has barrier effect built-in?
Second, when exit the synchoronized area, it should release the mutex lock
and flush the local memory to the main memory. But the
hythread_thin_monitor_exit method only release the mutex lock and I don't
find any flushing operation in hythread_thin_monitor_exit method.
I think there must be some mistakes of my idea, hoping for your advice.
> Thanks,
> Chengrong
>
>
>
>
Re: [drlvm][jitrino]
Posted by Xiao-Feng Li <xi...@gmail.com>.
Chengrong, atomic instruction (such as locked cmpxchg) itself has
barrier effect built-in; otherwise, it's hard to be atomic.
Thanks,
xiaofeng
On Dec 14, 2007 3:57 PM, 史成荣 <ic...@gmail.com> wrote:
> As we know, the key word of "synchronized" in Java will translated into
> monenter/monexit pair. And synchronization shoud contain two functions, One
> is the mutex lock and the other is the *memory barrier*. I traced the
> compiling pipeline from Java bytecode to LIR, found the monenter/monexit
> pair is finally transformed into some assembly codes among
> which there are codes to call the interface function provided by Thread
> Manager. But I didn't find any function provided by Thread Manager
> implementing the *memory barrier.* It seams that only the mutex lock is
> implemented.
> I don't know if I am right. Can anyone give some suggestions?
>
> Thanks,
> Chengrong
>
--
http://xiao-feng.blogspot.com