harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm][threading] Is it safe to use hythread_suspend_all and hythread_resume_all?
Date Wed, 18 Oct 2006 13:44:55 GMT
It seems we are not in sync.... I don't suggest changing current
suspention scheme...I like it.... I'm talking about one particular
case.....and still can't see any disadvantages in what I propose...

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.
>
> > 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
>
>

---------------------------------------------------------------------
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


Mime
View raw message