hmm.... I never thought of it that way. My initial reaction is no. Suspend enable/disable and global thread lock are seperate, distinct concepts. The thread lock should protect the VM internal thread structs when they are being modified. For example, the thread lock should allow only one thread create/die at any given instant. The enable/disable state is incidental to this event. This is independent of the concept of a thread running native code being in a state where the GC can find all its live references. If a thread needs to grab the thread lock, of course, it needs to put itself in a suspend enable mode because it might have to wait for the lock.
Yes I agree that global lock allows only one thread to create/die (and so on) at any given moment, while suspend_disable/enable affect only suspension functionality. But in fact suspend_disable is per_thread lock for suspension, and if it's taken(suspend_disable called) other thread can't suspend particular thread while this lock is not released(suspend_enable called). And I believe that additional synchronization is excessive and very expensive. Also my opinion is that suspension scheme is the last place in DRLVM that should be changed w/o any open issue or problem which is depends on it (or we do have a problems in GC in regard to suspension). Do you really think that current scheme is unsafe and should be redesigned? Nik. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
