harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][threading] Is it safe to use hythread_suspend_all and hythread_resume_all?
Date Thu, 19 Oct 2006 12:14:36 GMT
On 10/18/06, Nikolay Kuznetsov <nikolay.kuznetsov@gmail.com> wrote:
>
> > I agree it is required to have a solid model in mind. I also believe
> > it is required to have such design/implementation which doesn't allow
> > to break that model.
>
> No, that's the point if functionality is so safe that it's impossible
> to break the model,
> it's not so highly important(as in our case) to understand how it
> works, this model will restore itself.


hmmm.... this is probably a case where we are all saying the same thing only
using different words.  Nikolay, would it be possible for you to try a
different way of explaining the above?  It would really be appreciated.

> It's ok to have safe points inside disabled regions only if it is
> > really safe to enable GC at that point. All such cases should be taken
> > with extreme caution. In our particular case we can't guarantee that
> > it is safe to suspend the thread. That's why I think having something
> > like assert(hythread_is_suspend_enabled) in the beginning of
> > hythread_suspend_all is really required? Of cause it will require some
> > changes in VM and TM...
>
> Again, I agree that sometimes safepoints enable suspension in wrong
> places an assert must be placed inside conditions, for instance, but
> suspend_all is the rare place where safe_point placed in
> suspend_disable region intentionally, by design(please refer to the
> lock semantics of safe regions in my answer to Weldon).
>
> > Could you give the most impossible thing to do?
> Peace All Over the World? :)
>
> > I was thinking of TM
> > as of quite independent component. But now it seems like some parts of
> > it are really depend on DRLVM implementation. :-(
>
> First of all, TM _is_ independent component, but some of its functions
> designed for special usage(it's potentially unsafe to nail up smth
> with the gun, for instance).
> Also, I believe that TM suspension safe enough an should not be
> rewritten w/o special need, and even if it should the performance of
> this functionality should be always in mind.
> Current suspension scheme was tested on multiple workloads and tuned
> to achieve better performance, and note that not even using additional
> locks but having CAS to perform suspend_disable/enable leads to
> noticeable performance loss.
>
> Actually my idea from the beginning is that while we don't have a
> scenario we should not change suspension algorithm. It's good enough,
> robust tuned for better performance of GC.
>
> Nik.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message