harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm][shutdown] How to cleanup resources safely?
Date Tue, 21 Nov 2006 12:10:25 GMT
Evgueni Brevnov wrote:
> On 11/21/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>> 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?
> Xiao-Feng, the process is not necessarily stopped. The invocation API
> defines standard way to create/destroy VM instances. Thus VM
> destroying doesn't mean process termination.

Absolutely, the goal should be to be able to create and destroy VM's in
a long running loop without leaking resources.

>> And the requirement below for all the native threads to comply with TM
>> rule sounds like unrealistic.
> It is good that you asked this question. (So you read my proposal
> more-or-less carefully :-)). Let me describe this part in more
> details. There are two different kind of native threads. Lets call
> them user and helper threads. The difference is that user threads are
> created by the application native code while helper threads are
> created by VM components. There is no chance for a user thread to
> interact with VM until the thread is not attached to VM. So there is
> no need to care about such threads. (User should care by itself :-))

Agreed.  If the thread has no interaction with the VM, say it is created
by a third-party library that knows nothing of the VM, then we cannot
help and it must clean up itself.  However, the resource management API
we define should be generic, so we can register a callback to such
third-party libraries if they have a clean-up function we need to call.

> The helper threads are created by VM components and may access VM data
> through inter-component interfaces. Thus we need to be sure that no
> such threads are running before destroying VM-wide data.

Yep, that is part of the shutdown sequence.  As I wrote elsewhere we
should describe the state of the VM data at the point the callbacks are
invoked, and limit the operations that are permissible in the callback
function, e.g. creating a new Thread to run arbitrary Java code is
likely disallowed <g>.



Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message