#26 thread is birthing when clinit() locking

[Xiao-Feng Li]

bug report by ORP user Cloud from mobilian@netsgo.com:

I found a problem, which, I guess, is related
with "thread status transition"..
-------------------------------------------------------
ThreadTest.java
-------------------------------------------------------

class Thread1 extends Thread {
public void run() {
System.out.println("in Thread1.run" );
}
}

class ThreadTest {
static {
Thread th = new Thread1();
th.start();

try {
System.out.println("before synchronized");
synchronized(ThreadTest.class) {
System.out.println("in synchronized");
}
} catch(Exception e) {
}
}

public static void main(String args[] ) {
System.out.println("!!! main --- START");
System.out.println("!!! main --- END");
}
}

-------------------------------------------------------
Result of SUN java.exe
-------------------------------------------------------
before synchronized
in synchronized
!!! main --- START
!!! main --- END
in Thread1.run

-------------------------------------------------------
Result of ORP
-------------------------------------------------------
before synchronized
Assertion failed: (p_current_orpthread->app_status ==
thread_is_running) || (p_current_orpthread->app_status
==
thread_is_dying), file d:\kona\orp105_0821\base_
natives\common\mon_enter_exit.cpp, line 295

.....................................................

As you can see in the source, 'monitorenter'
or 'moniterexit' can be
executed by main thread BEFORE main thread gets
into "thread_is_running" state.

As you know, a thread changes it's state
from "thread_is_birthing"
to "thread_is_running" only when the thread invokes
main() or invokes
run(). And the thread cannot do 'monitor-related
operation' properly
before "thread_is_running" state.

Actually, in the examle BEFORE main thread gets
into "thread_is_running" state, the Thread1 thread
tries to do
monitor-related work and it causes a problem.

Can you explain in detail about this problem and
solution also?

Cloud.

[Xiao-Feng Li]

Logged In: YES
user_id=202559

Yes this is a problem with p_thr->app_status transition.
It turns out that during orp initialization p_thr-
>app_status == thread_is_birthing until after the static
initializer has run. This is inconsistent since the thread
is, of course, running the initializer so should instead be
in the state thread_is_running.

I tried to fix the bug by putting p_thr->app_status ==
thread_is_running; in orp_thread_init(). But then I hit
the following warning message code in orp_enable_gc().
Perhaps a new app_status enum state needs to be added
called main_thread_is_birthing. Also add the correct logic
to the below code.

if (the_ljf == 0) {
// If "ljf" is zero, the thread had better
be "birthing" or "dying".
if (!((p_thr->app_status == thread_is_dying) ||
(p_thr->app_status == thread_is_birthing)) ||
(p_thr->throw_context != NULL)) {
// We could be compiling main so there won't be
an ljf
if (print_bug_not_done) {
orp_cout << "*** BUG *** - orp_enable_gc:
p_thr->last_java_frame is 0 and p_thr->app_status is " \ << p_thr->app_status;

Weldon