Opened 10 years ago

Last modified 8 years ago

#33 closed task

Resolve the main thread issue — at Initial Version

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

Description

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.

GCC/VAC

Change History (0)

Note: See TracTickets for help on using tickets.