Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of xiaofeng.li@gmail.com
 designates 66.249.92.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=tKymXn/+n06rM264GbsHKathGCqGbVYJlys8pbFb+FHfQh3JcryIWirmhRcczkLnC4VOJrfxK3WOM839A+T5581TjQBULjOYiELFsZIqbAi2AZuNX0UK+sYseYyAAbLmKD4CE4PjPcgQ/dH9kn+C7C4q7Co/C1f34QNSpA4ZZA0=
Message-ID: <9623c9a50611202149h5169e134n4035d07c7effb784@mail.gmail.com>
Date: Tue, 21 Nov 2006 13:49:56 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][shutdown] How to cleanup resources safely?
In-Reply-To: <e29119980611200144m172f64adw1829c86fb672b7d6@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e29119980611200144m172f64adw1829c86fb672b7d6@mail.gmail.com>

On 11/20/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> Hi All,
>
> I'd like to share with you my findings regarding current DRLVM
> shutdown procedure (not in too many details) and discuss further steps
> to improve it.
>
> /* General words about shutdown */
>
> Here is a snip from the j.l.Runtime.addShutdownHook() spec:
>
> "The Java virtual machine shuts down in response to two kinds of events:
> 1) The program exits normally, when the last non-daemon thread exits
> or when the exit (equivalently, System.exit) method is invoked, or
> 2) The virtual machine is terminated in response to a user interrupt,
> such as typing ^C, or a system-wide event, such as user logoff or
> system shutdown."
>
> Except these 2 events there is one more player on the scene. It is
> DestroyJavaVM defined by invocation API.User calls DestroyJavaVM to
> request reclamation of  all resources owned by the VM.
>
> As it was discussed earlier (and I think agreed) the System.exit()
> should terminate entire process the VM is running in right after it
> executed shutdown hooks and finalizes. At least RI does so. Thus I
> would like to look closer at the case when the last non-daemon thread
> exits and the VM is requested to cleanup resources through
> DestroyJavaVM. When DestroyJavaVM is called it waits until current
> thread is the last non-daemon thread before cleaning up all resources
> owned by the VM. It is important to note it is still possible daemon
> java and native threads are running inside the VM even if there is no
> running non-daemon threads.  These running threads may still be using
> VM-wide data (generally located in Global_Env). Thus before cleaning
> resources up we need to stop these threads somehow. Unfortunately, we
> can't just kill threads. We need to release all resources (system
> locks, heap/stack memory, open files/connections, etc) owed by each
> thread. So the problem I'd like to discuss and solve: How to stop
> running threads in a safe manner?

Evgueni, when the process is stopped, why do we need care about the
system resource in details if they are released by the system
automatically?

And the requirement below for all the native threads to comply with TM
rule sounds like unrealistic.

Thanks,
xiaofeng

> /* Current DRLVM implementation */
>
> Currently, the DRLVM isn't able to stop running threads in a safe way.
> Thus it just doesn't clean resources up if there are running threads
> after all non-daemon threads exits.
>
> /* How to stop threads safely. Proposal. */
>
> I propose to consider native and java threads separately. Lets start
> with native threads.
>
> Native threads: It seems there is not much we can do to stop arbitrary
> native thread and release resources owed by it. I don't consider
> global resource management as a possible solution here :-). Thus there
> are two requirements for native threads to ensure safe VM shutdown:
>
> a) Any native thread must be created by TM or attached to TM. So TM is
> aware about all running native threads.
> b) Native thread provides a callback which is called to request thread
> shutdown. It's the native thread responsibility to clean its resources
> upon shutdown request.
>
> Java threads: We have much more control other java threads. Namely it
> is possible to unwind the stack in a safe way. When the VM needs to
> stop a java thread it asynchronously raises an exception to that
> thread. The VM ensures that the exception will not be caught by any
> java exception handler (ala j.l.ThreadDeath exception). This guarantee
> full and safe java stack unwinding. If there is no user native frames
> on the stack (JNI calls) then thread exits normally otherwise the
> control is returned to the user's code with an exception raised. It is
> the user's responsibility to handle exception properly and clean up
> all resources allocated by native code.
>
> Any suggestions/comments are HIGHLY welcome.
>
> Thanks
> Evgueni
>