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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]