Opened 14 years ago

Last modified 13 years ago

#33 closed task

Resolve the main thread issue — at Version 1

Reported by: dmik Owned by:
Priority: major Milestone: GA2
Component: general Version:
Severity: low Keywords:
Cc:

Description (last modified by dmik)

Java never starts VM execution on the main thread of the process. It instead fires off a new thread (right after performing basic parsing of command line arguments) and starts the VM there. The main thread then waits indefinitely for this new thread to terminate and once terminated, it returns from main().

This has one strange effect. Java uses many additional DLLs for implementing native methods and for providing utility functions and these DLLs often use C++ classes. These classes have static objects that get created at program startup and destroyed at program termination. These objects sometimes use various JVM calls.

The thing is that the destruction of static objects always happens on the main thread, after all other threads of the process have been stopped (at least this is the case for VAC/GCC on OS/2 where such destruction either takes place at DLL termination time (GCC) or during DosExitList processing (VAC)).

So, in case of static objects in helper Java DLLs, their destruction happens after the JVM has been exited and therefore calling it will simply crash (becaus most internal structures have been destroyed by the exit routine).

This in particular happens with AWT native methods which are implemented with the help of C++ classes on Windows (and therefore on OS/2). A particular example is the static GDIHashable AwtPen::cache object (see awt_Pen.cpp). Upon destruction, it frees memory and in the debug build the free routine collects some extra information and uses the JVM monitor primitive to serialize access to its internal structures containing this information. But this primitive may not function when JVM is shut down and therefore the application crashes.

Change History (1)

comment:1 by dmik, 14 years ago

Description: modified (diff)
Milestone: Beta

JFTR. I found this problem when I discovered that the debug Java build always crashes in ODINCRTD.DLL when KERNEL32.DLL tries to write something to the odin32.log file. I didn't have time to work on that before (taking into account that it happens only in the debug build) but today I looked at it and found a problem which I described in http://svn.netlabs.org/odin32/ticket/19. I changed AWT.DLL so that it calls its destructors through DosExitList, e.g. when Odin CRT is still in place and usable, and the ODINCRTD.DLL crash had gone. But then I discovered the problem I describe in this ticket.

Note: See TracTickets for help on using tickets.