harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: DestroyJavaVM, System.exit, etc
Date Tue, 12 Feb 2008 14:55:05 GMT
Evgueni, Pavel, thanks!
I have renamed the method into exec_native_shutdown_sequence() so it
would sound alike a native wrapper exec_shutdown_sequence() of java
execShutdownSequence() which is called right before my method in all
three places. Are you ok with this name?

Thanks!



On Feb 12, 2008 7:53 AM, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> Alexey,
>
> There is one important thing to understand. When
> Java_java_lang_VMExecutionEngine_exit is called there are other
> threads running. So we should ensure safe access to shared data from
> this place. In particular while it's striclty prohibitied to
> deallocate shared resources at this point it's ok to print out some
> info. That's why I would recommend to rename vm_native_shutdown() to
> avoid confusion in future.
>
> Thanks
> Evgueni
>
>
> On 2/11/08, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> > Evgueni,
> > Thanks for your reference to an additional thread attach at
> > jni.cpp:1490 with respect to the double thread detach. That was
> > explanation I was looking for. It would be a great help if you found
> > few minutes to scan the short patch at HARMONY-5481 to understand if I
> > don't break the intended model by adding void vm_native_shutdown()
> > function call.
> >
> > Thanks!
> >
> > [1] http://issues.apache.org/jira/browse/HARMONY-5481
> >
> >
> > On Feb 11, 2008 3:52 PM, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> > > On 2/11/08, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> > > > Hello Evgueni,
> > > > Thank you for your explanations. I was reading [1] on invocation API.
> > > > I have not found anything specific in this document, moreover the
> > > > example in this document does not detach the main thread. Is it up to
> > > > date version?
> > > >
> > >
> > > In early versions it was prohibited to call DestroyJavaVM by
> > > unattached thread. Later this restriction was eliminated. So it's up
> > > to user whether to call DestroyJavaVM from attached thread or not.
> > > Unfortunately, J9 VM doesn't handle uncaught exceptions properly if we
> > > don't call DetachCurrentThread explicitly. This is the reason behind
> > > the code we currently have.
> > >
> > > Thanks
> > > Evgueni
> > >
> > >
> > > > Shortly, the comment and related change confuse me in a following way:
> > > > it seems that thread detach was added before java shutdown sequence is
> > > > executed.
> > > >
> > > > Thanks.
> > > >
> > > > [1] http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/invocation.html
> > > >
> > > > On Feb 11, 2008 8:37 AM, Evgueni Brevnov <evgueni.brevnov@gmail.com>
wrote:
> > > > > Alexey,
> > > > >
> > > > > On 2/10/08, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> > > > > > Gregory,
> > > > > >
> > > > > > Thanks for your answers! I have created a patch which modifies
> > > > > > shutdown sequence slightly unifying DestroyJavaVM, System.exit()
and
> > > > > > Ctrl+C shutdown paths [1]. Could you please look at it?
> > > > > >
> > > > > > The question on thread detachment is actually provoked by confusing
> > > > > > comment in our launcher:
> > > > > >
> > > > > >  /* Updated in the 6.0 spec, we can now detach the main thread
before
> > > > > > calling DestroyJavaVM,
> > > > > >     and we must if we wish main thread uncaught exception handlers
to
> > > > > > be called. */
> > > > > >  (*jvm)->DetachCurrentThread(jvm);
> > > > > >  (*jvm)->DestroyJavaVM (jvm);
> > > > > >
> > > > >
> > > > > Why do you think the comment in launcher is confusing? It just says
> > > > > that starting from spec update 6.0 it is allowed to call DestroyJavaVM
> > > > > by detached thread.
> > > > > It's perfectly right to detach main thread before calling
> > > > > DestroyJavaVM. It was done to workaround J9 behaviour. I think some
of
> > > > > your questions may disappear if you carefully read invocation API
> > > > > specification.
> > > > >
> > > > >
> > > > > > It seems that the thread is detached second time from inside
of
> > > > > > DestroyJavaVM function, see vm_destroy():
> > > > > >    // Detach current main thread.
> > > > > >    status = jthread_detach(java_thread);
> > > > > >
> > > > > > Fortunately, the java code from execShutdownSequence from
> > > > > > vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java
launches
> > > > > > shutdown hooks in separate threads, so the early detach does
not cause
> > > > > > any problems for the hooks. May be we should attach the thread
back in
> > > > > > vm_destroy to execute java code of execShutdownSequence.
> > > > > >
> > > > >
> > > > > We definitely must execute shutdown sequence by attached thread.
> > > > >
> > > > > Thanks
> > > > > Evgueni
> > > > >
> > > > >
> > > > > > Thanks again.
> > > > > >
> > > > > > [1] http://issues.apache.org/jira/browse/HARMONY-5481
> > > > > >
> > > > > > On Feb 9, 2008 5:02 PM, Gregory Shimansky <gshimansky@apache.org>
wrote:
> > > > > > > Alexei Fedotov said the following on 09.02.2008 16:34:
> > > > > > > > Hello, folks,
> > > > > > > > I have some problems trying to understand the current
Harmony VM
> > > > > > > > shutdown mechanism. I would appreciate any help from
you.
> > > > > > > >
> > > > > > > >    * What is a correct place to put my own C shutdown
code?
> > > > > > >
> > > > > > > It depends on how the application shuts down. It if finishes
all
> > > > > > > non-daemon threads, then vm_destroy is a good place. Keep
in mind that
> > > > > > > shutdown sequence is very fragile and it is easy to break
it. If
> > > > > > > application exits with System.exit, then the only place
is before
> > > > > > > _exit() in Java_java_lang_VMExecutionEngine_exit.
> > > > > > >
> > > > > > > >    * Why does VM detach the main thread from both
the launcher and
> > > > > > > > vm_destroy function?
> > > > > > >
> > > > > > > I didn't get the question. Do you mean that main thread
is attached in
> > > > > > > the DestroyJavaVM function? It is done because at shutdown
VM has to
> > > > > > > execute shutdown hooks, and therefore it has to execute
Java on an
> > > > > > > attached thread.
> > > > > > >
> > > > > > > >    * What is the reason for the global monitor locks
and unlocks in
> > > > > > > > the following function? What means the comment about
jobjectArray?
> > > > > > > > JNIEXPORT void JNICALL Java_java_lang_VMExecutionEngine_exit
> > > > > > > >   (JNIEnv * jni_env, jclass, jint status, jboolean
needFinalization,
> > > > > > > > jobjectArray)
> > > > > > > > {
> > > > > > > >     // ToDo: process jobjectArray
> > > > > > > >     hythread_global_lock();
> > > > > > > >     _exit(status);
> > > > > > > >     hythread_global_unlock();
> > > > > > > > }
> > > > > > >
> > > > > > > It was done to fix the bug HARMONY-5167. Somehow threads
could be
> > > > > > > created even when _exit() function is executed, so final
heap check
> > > > > > > could produce an error on windows in debug mode.
> > > > > > >
> > > > > > > >    * Where are VM resources reclaimed on shutdown?
I found the only
> > > > > > > > apr_pool_destroy(java_vm->pool) in DestroyJavaVM().
Are there any
> > > > > > > > other places?
> > > > > > >
> > > > > > > The main place is Global_Env::~Global_Env() in Environment.cpp.
This
> > > > > > > destructor is called only in case VM exits normally. For
System.exit
> > > > > > > destructors are not executed.
> > > > > > >
> > > > > > > --
> > > > > > > Gregory
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > With best regards,
> > > > > > Alexei
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > With best regards,
> > > > Alexei
> > > >
> > >
> >
> >
> >
> > --
> > With best regards,
> > Alexei
> >
>



-- 
With best regards,
Alexei

Mime
View raw message