harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [drlvm][threading] H3289 -- some JVMTI questions
Date Fri, 16 Mar 2007 15:54:59 GMT
Weldon Washburn wrote:
> On another topic, do we really have to use Thread.stop() in the
> implementation of vm_shutdown_stop_java_threads() ?  This seems way
> too hard.   All we really want to do is give back all the OS resources.  We
> could simply call OS kill on each specific thread, return all memory via
> "free()", return all file handles, etc.  Note if there was no need to allow
> multiple JVMs in a single address space to come and go, we could simplify
> the above and basically just call process exit().

HARMONY-3381 (already committed) replaces Thread.stop-like shutdown algorithm
to the following one

1) set a shutdown callback, which executes hythread_exit() (which delegates to
either pthread_exit() or ExitThread())

2) wait for a little while -- this is a little bit "unscientific" and assumes,
that all actively running threads will reach a callback safepoint within that
"little while". If assumption holds true, the remaining threads are highly
likely to be unactive threads, i.e. sleeping, waiting or blocked.
The key about a little while is that if all threads has terminated promptly, we
don't need to wait any longer at all. It is currently implemented using
hythread_join() with timeout.

3) on the third step the remaining threads are terminated using
hythread_cancel() (which delegates to either of pthread_cancel() or
TerminateThread()) -- This step is inherently dangerous on Windows, as
terminated thread may be holding system-wide malloc lock, and subsequent free()
on a main thread will deadlock. Fortunately, the unscientific assumption of the
step (2) makes this rather unprobable.

Using pthread_cancel() on linux has its own set of advantages and
disadvantages. By default, threads are created with cancellability enabled and
in "deferred cancellability" state. It means that pthread_cancel() will only
terminate thread when it reaches an explicit cancellation point, such as
pthread_cond_wait(). In this way, pthread_cancel() does not suffer from the
malloc-deadlock issue.

However, deferred cancellability brings its own problems, for example, as
pthread_mutex_lock is not a cancellation point, a pair of deadlocked daemon
threads will still be alive during VM shutdown, and could probably result in
EINVAL return and subsequent assertion failure if the monitors are destroyed in
the main shutdown thread.

So, the shutdown algorithm has been improved compared to the former
exception-based approach, like Thread.stop(), but still is not perfect.
Eugene and me discussed this and agreed to keep an open eye on shutdown bugs.
There is still a field for experiments and possible improvements, e.g. using
asynchronous cancellability or even using pthread_kill instead of
pthread_cancel to implement immediate thread termination.

-- 
Salikh Zakirov


Mime
View raw message