Skip to main content

JVM porting related

10 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Dean Long

Take a look at handleSegv() in

src/linux-mips/javavm/runtime/segvhandler_arch.c

The signal handler is installed with the SA_SIGINFO flag, so
that it has access to the extra

siginfo_t* info, struct ucontext* ucp

args when a signal happens. Alternatively, run with gdb already
attached, so gdb will catch the signal 11 when it happens instead
of after it has been handled by pthread_sighandler()

Dean

On 3/15/2010 2:02 AM, phonemeadvanced@mobileandembedded.org wrote:
> OK . Thanks
>
> i have taken the disassembly before 0x2004e984 and it is too long , not found any thing too suspicious.
> Also i didn't get you in the case of PC printing inside crash() ?
> [Message sent by forum member 'kanu123' (gopinadhanrenjith@in.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=391872
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

kanu123
Offline
Joined: 2010-03-01

Can you please give me your contact info ?

Dean Long

Renjith, you might want to check which instruction in
__moddi3 is causing the crash.

dl

On 3/11/2010 5:27 PM, Hinkmond Wong wrote:
> Hi Renjith,
>
> Moving your questions over to the advanced@phoneme.dev.java.net mail
> alias which is the proper forum for this type of question.
>
> Renjith G wrote:
>> hi ,
>>
>> I have ported the phoneme JVM source code into our processor (Xtensa ,
>> core - C1LX2). But some problem has occurred when i run the Test.java
>> above the ported JVM in my board.
>>
>> In the test suite(Test.java) , when we call *"testSunMiscGC()"*
>> function and GC thread is invoked by "*GC.requestLatency((long)2000)"
>> *(Assumption: GC thread comes into picture after 2 ms?),and then the
>> thread goes to sleep for 5ms right? After this we cancels the latency
>> request in the main thread( by *"latencyRequest.cancel()"* ). After
>> this ,we call *"testManyFieldsAndMethods() "* and allocates a big
>> memory in it. At this time the whole test crashed and thrown *signal 11*.
>>
>> When i put one sleep for 1ms after the *"latencyRequest.cancel()"*
>> then the whole test become passed with out any problem. Also the whole
>> test cases pass when we comment the *"testSunMiscGC()"*
>>
>>
>> I debugged many times using the gdb at crash point. I am attaching the
>> backtrace along with this mail.
>>
>> My assumption is that , the GC thread is still running and which
>> caused the crash during the call "testManyFieldsAndMethods()" even
>> after the request has been cancelled by calling
>> *"latencyRequest.cancel()" *.
>>
>> Then my doubts:
>>
>> 1) For how long will the GC run when we call *"GC.LatencyRequest
>> latencyRequest = GC.requestLatency((long)2000)"*
>>
>> 2) Is there any test case description for Test.java ?
>>
>> 3) Will the GC run before the call manually *"GC.LatencyRequest
>> latencyRequest = GC.requestLatency((long)2000)"* ?
>>
>> 4) Also i have more memory , that shouldn't cause any overflow error.
>>
>> 5) Also by looking the bt, i can't trace main, GC, threads which are
>> running (total 4 threads. ) , Can you?
>
>
> First, tell us more about your Xtensa processor. What operating system
> is running on it? Is it Linux? If so, which distro?
>
>
> Thanks,
> Hinkmond
>
>
>>
>>
>> Expecting your co operation ,
>>
>>
>> /renjith g
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

kanu123
Offline
Joined: 2010-03-01

Thanks.

Taken the disassembly at the location where the __moddi3 occured and which is attached below,

(gdb) thread 1
[Switching to thread 1 (Thread 1024 (LWP 788))]#0 0x2002cd54 in kill ()
from /lib/libc.so.0
(gdb) where
#0 0x2002cd54 in kill () from /lib/libc.so.0
#1 0x004a5450 in crash (sig=11)
at ../../src/linux/javavm/runtime/sync_md.c:504
#2 0x20010cb1 in pthread_sighandler () from /lib/libpthread.so.0
#3 0x2004e984 in __moddi3 (u=, v=4596841238673811844)
at /opt/buildroot/toolchain_build_xtensa_c1lx2/gcc-4.2.1/gcc/libgcc2.c:1101
(gdb) disassemble 0x2004e984
Dump of assembler code for function __default_sa_restorer:
0x2004e984 <__default_sa_restorer+0>: movi a2, 225
0x2004e987 <__default_sa_restorer+3>: syscall
0x2004e98a <__default_sa_restorer+6>: excw
End of assembler dump.[b][/b]

/renjith g[b][/b]

Dean Long

Gdb could be confused about the actual location of the crash.
Try looking at the instructions before 0x2004e984 to see if they
look suspicious. You can also modify crash() so that it prints out
the PC of the crash.

On 3/14/2010 10:10 PM, phonemeadvanced@mobileandembedded.org wrote:
> Thanks.
>
> Taken the disassembly at the location where the __moddi3 occured and which is attached below,
>
> (gdb) thread 1
> [Switching to thread 1 (Thread 1024 (LWP 788))]#0 0x2002cd54 in kill ()
> from /lib/libc.so.0
> (gdb) where
> #0 0x2002cd54 in kill () from /lib/libc.so.0
> #1 0x004a5450 in crash (sig=11)
> at ../../src/linux/javavm/runtime/sync_md.c:504
> #2 0x20010cb1 in pthread_sighandler () from /lib/libpthread.so.0
> #3 0x2004e984 in __moddi3 (u=, v=4596841238673811844)
> at /opt/buildroot/toolchain_build_xtensa_c1lx2/gcc-4.2.1/gcc/libgcc2.c:1101
> (gdb) disassemble 0x2004e984
> Dump of assembler code for function __default_sa_restorer:
> 0x2004e984<__default_sa_restorer+0>: movi a2, 225
> 0x2004e987<__default_sa_restorer+3>: syscall
> 0x2004e98a<__default_sa_restorer+6>: excw
> End of assembler dump.[b][/b]
>
> /renjith g[b][/b]
> [Message sent by forum member 'kanu123' (gopinadhanrenjith@in.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=391855
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

kanu123
Offline
Joined: 2010-03-01

OK . Thanks

i have taken the disassembly before 0x2004e984 and it is too long , not found any thing too suspicious.
Also i didn't get you in the case of PC printing inside crash() ?

kanu123
Offline
Joined: 2010-03-01

Also can i call you ? your mobile/LL number ?
so that u will get the clear cut idea on this?

Hinkmond Wong

Hi Renjith,

Moving your questions over to the advanced@phoneme.dev.java.net mail
alias which is the proper forum for this type of question.

Renjith G wrote:
> hi ,
>
> I have ported the phoneme JVM source code into our processor (Xtensa
> , core - C1LX2). But some problem has occurred when i run the
> Test.java above the ported JVM in my board.
>
> In the test suite(Test.java) , when we call *"testSunMiscGC()"*
> function and GC thread is invoked by "*GC.requestLatency((long)2000)"
> *(Assumption: GC thread comes into picture after 2 ms?),and then the
> thread goes to sleep for 5ms right? After this we cancels the latency
> request in the main thread( by *"latencyRequest.cancel()"* ). After
> this ,we call *"testManyFieldsAndMethods() "* and allocates a big
> memory in it. At this time the whole test crashed and thrown *signal
> 11*.
>
> When i put one sleep for 1ms after the *"latencyRequest.cancel()"*
> then the whole test become passed with out any problem. Also the whole
> test cases pass when we comment the *"testSunMiscGC()"*
>
>
> I debugged many times using the gdb at crash point. I am attaching
> the backtrace along with this mail.
>
> My assumption is that , the GC thread is still running and which
> caused the crash during the call "testManyFieldsAndMethods()" even
> after the request has been cancelled by calling
> *"latencyRequest.cancel()" *.
>
> Then my doubts:
>
> 1) For how long will the GC run when we call *"GC.LatencyRequest
> latencyRequest = GC.requestLatency((long)2000)"*
>
> 2) Is there any test case description for Test.java ?
>
> 3) Will the GC run before the call manually *"GC.LatencyRequest
> latencyRequest = GC.requestLatency((long)2000)"* ?
>
> 4) Also i have more memory , that shouldn't cause any overflow error.
>
> 5) Also by looking the bt, i can't trace main, GC, threads which are
> running (total 4 threads. ) , Can you?

First, tell us more about your Xtensa processor. What operating system
is running on it? Is it Linux? If so, which distro?

Thanks,
Hinkmond

>
>
> Expecting your co operation ,
>
>
> /renjith g

[att1.html]

(gdb) thread 1
[Switching to thread 1 (Thread 1024 (LWP 3694))]#0 0x2002cd54 in kill ()
from /lib/libc.so.0
(gdb) where
#0 0x2002cd54 in kill () from /lib/libc.so.0
#1 0x004a5450 in crash (sig=11)
at ../../src/linux/javavm/runtime/sync_md.c:504
#2 0x20010cb1 in pthread_sighandler () from /lib/libpthread.so.0
#3 0x2004e984 in __moddi3 (u=, v=4599268891628464516)
at /opt/buildroot/toolchain_build_xtensa_c1lx2/gcc-4.2.1/gcc/libgcc2.c:1101

(gdb) thread 2
[Switching to thread 2 (Thread 2049 (LWP 3695))]#0 0x2002d2c0 in poll ()
from /lib/libc.so.0
(gdb) where
#0 0x2002d2c0 in poll () from /lib/libc.so.0
#1 0x2000f66d in __pthread_manager () from /lib/libpthread.so.0
#2 0x2002be50 in clone () from /lib/libc.so.0

(gdb) thread 3
[Switching to thread 3 (Thread 1026 (LWP 3696))]#0 0x2002dc55 in sigsuspend
() from /lib/libc.so.0
(gdb) where
#0 0x2002dc55 in sigsuspend () from /lib/libc.so.0
#1 0x200119d9 in __pthread_wait_for_restart_signal ()
from /lib/libpthread.so.0
#2 0x2000ebcc in suspend () from /lib/libpthread.so.0
#3 0x2000ee00 in pthread_cond_wait () from /lib/libpthread.so.0
#4 0x004a5252 in CVMcondvarWait (c=0x5e435c, m=0x5e4344, millis=0)
at ../../src/linux/javavm/runtime/sync_md.c:340
#5 0x004482b1 in CVMreentrantMutexWait (ee=0x5e4780, rm=0x5e433c,
c=0x5e435c, millis=0) at ../../src/share/javavm/runtime/sync.c:217
#6 0x004483b6 in CVMsysMonitorWait (ee=0x5e4780, mon=0x5e433c, millis=0)
at ../../src/share/javavm/runtime/sync.c:303
#7 0x00441cc5 in CVMprivateWait (ee=0x5e4338, indirectObj=0x5e4780,
millis=6177592, fast=0) at ../../src/share/javavm/runtime/objsync.c:1861
#8 0x00441fc4 in CVMdetWait (ee=0x5e4780, indirectObj=0x5e49d8, millis=0)
at ../../src/share/javavm/runtime/objsync.c:2101
#9 0x004434a0 in CVMgcSafeObjectWait (ee=0x5e4780, o=0x5e49d8, millis=0)
at ../../src/share/javavm/runtime/objsync.c:3365
#10 0x00470628 in Java_java_lang_Object_wait (env=0x5e47ac, obj=0x5e49d8,
millis=0) at ../../src/share/javavm/runtime/jvm.c:1677
#11 0x004b65f4 in label ()
at ../../src/xtensa/javavm/runtime/invokeNative_xtensa.S:201
#12 0x004409dd in CVMinvokeJNIHelper (ee=0x5e4780, mb=0x400000)
at ../../src/share/javavm/runtime/interpreter.c:4284
#13 0x004b5641 in CVMgcUnsafeExecuteJavaMethod (ee=0x3, mb=0x3f5ff940,
isStatic=6017564, isVirtual=3)
at ../../src/share/javavm/runtime/executejava_standard.c:3718
#14 0x00468049 in CVMjniInvoke (env=0x0, obj=0xfffffe00, methodID=0x102,
pushArguments=0x100, args=0x2, info=11, retValue=0x0)
at ../../src/share/javavm/runtime/jni_impl.c:2703
#15 0x00469a2b in CVMjniCallVoidMethod (env=0x0, obj=0x5e4914,
methodID=0x5c94e4) at ../../src/share/javavm/runtime/jni_impl.c:2926
#16 0x0047105b in start_func (arg=0x2005c59c)
at ../../src/share/javavm/runtime/jvm.c:1947
#17 0x004a3bda in start_func (a=0x5e4670)
at ../../src/portlibs/posix/posix_threads_md.c:48
#18 0x2000f40d in pthread_start_thread () from /lib/libpthread.so.0
#19 0x2002be50 in clone () from /lib/libc.so.0

(gdb) thread 4
[Switching to thread 4 (Thread 2051 (LWP 3697))]#0 0x2002dc55 in sigsuspend
() from /lib/libc.so.0
(gdb) where
#0 0x2002dc55 in sigsuspend () from /lib/libc.so.0
#1 0x200119d9 in __pthread_wait_for_restart_signal ()
from /lib/libpthread.so.0
#2 0x2000ebcc in suspend () from /lib/libpthread.so.0
#3 0x2000ee00 in pthread_cond_wait () from /lib/libpthread.so.0
#4 0x004a5252 in CVMcondvarWait (c=0x5e430c, m=0x5e42f4, millis=0)
at ../../src/linux/javavm/runtime/sync_md.c:340
#5 0x004482b1 in CVMreentrantMutexWait (ee=0x5e7f30, rm=0x5e42ec,
c=0x5e430c, millis=0) at ../../src/share/javavm/runtime/sync.c:217
#6 0x004483b6 in CVMsysMonitorWait (ee=0x5e7f30, mon=0x5e42ec, millis=0)
at ../../src/share/javavm/runtime/sync.c:303
#7 0x00441cc5 in CVMprivateWait (ee=0x5e42e8, indirectObj=0x5e7f30,
millis=6177512, fast=1) at ../../src/share/javavm/runtime/objsync.c:1861
#8 0x00441dd0 in CVMfastWait (ee=0x5e7f30, indirectObj=0x5e81b4, millis=0)
at ../../src/share/javavm/runtime/objsync.c:1920
#9 0x004434a0 in CVMgcSafeObjectWait (ee=0x5e7f30, o=0x5e81b4, millis=0)
at ../../src/share/javavm/runtime/objsync.c:3365
#10 0x00470628 in Java_java_lang_Object_wait (env=0x5e7f5c, obj=0x5e81b4,
millis=0) at ../../src/share/javavm/runtime/jvm.c:1677
#11 0x004b65f4 in label ()
at ../../src/xtensa/javavm/runtime/invokeNative_xtensa.S:201
#12 0x004409dd in CVMinvokeJNIHelper (ee=0x5e7f30, mb=0x400000)
at ../../src/share/javavm/runtime/interpreter.c:4284
#13 0x004b5641 in CVMgcUnsafeExecuteJavaMethod (ee=0x3, mb=0x3f3ff940,
isStatic=6017564, isVirtual=3)
at ../../src/share/javavm/runtime/executejava_standard.c:3718
#14 0x00468049 in CVMjniInvoke (env=0x0, obj=0xfffffe00, methodID=0x102,
pushArguments=0x100, args=0x2, info=11, retValue=0x0)
at ../../src/share/javavm/runtime/jni_impl.c:2703
#15 0x00469a2b in CVMjniCallVoidMethod (env=0x0, obj=0x5e80c4,
methodID=0x5c94e4) at ../../src/share/javavm/runtime/jni_impl.c:2926
#16 0x0047105b in start_func (arg=0x2005c778)
at ../../src/share/javavm/runtime/jvm.c:1947
#17 0x004a3bda in start_func (a=0x5e4670)
at ../../src/portlibs/posix/posix_threads_md.c:48
#18 0x2000f40d in pthread_start_thread () from /lib/libpthread.so.0
#19 0x2002be50 in clone () from /lib/libc.so.0
(gdb)

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

Renjith G

Thanks Hinkmond

This link will give you a brief idea about xtensa processors
http://www.tensilica.com/uploads/pdf/xtensa_LX2_April07.pdf

Also we are running linux in the board as the operating system and its
flavor is * "Linux A2000 2.6.29-rc7**"
*

/renjith g*
*

Hinkmond Wong wrote:
> Hi Renjith,
>
> Moving your questions over to the advanced@phoneme.dev.java.net mail
> alias which is the proper forum for this type of question.
>
> Renjith G wrote:
>> hi ,
>>
>> I have ported the phoneme JVM source code into our processor (Xtensa
>> , core - C1LX2). But some problem has occurred when i run the
>> Test.java above the ported JVM in my board.
>>
>> In the test suite(Test.java) , when we call *"testSunMiscGC()"*
>> function and GC thread is invoked by "*GC.requestLatency((long)2000)"
>> *(Assumption: GC thread comes into picture after 2 ms?),and then the
>> thread goes to sleep for 5ms right? After this we cancels the latency
>> request in the main thread( by *"latencyRequest.cancel()"* ). After
>> this ,we call *"testManyFieldsAndMethods() "* and allocates a big
>> memory in it. At this time the whole test crashed and thrown
>> *signal 11*.
>>
>> When i put one sleep for 1ms after the *"latencyRequest.cancel()"*
>> then the whole test become passed with out any problem. Also the
>> whole test cases pass when we comment the *"testSunMiscGC()"*
>>
>>
>> I debugged many times using the gdb at crash point. I am attaching
>> the backtrace along with this mail.
>>
>> My assumption is that , the GC thread is still running and which
>> caused the crash during the call "testManyFieldsAndMethods()" even
>> after the request has been cancelled by calling
>> *"latencyRequest.cancel()" *.
>>
>> Then my doubts:
>>
>> 1) For how long will the GC run when we call *"GC.LatencyRequest
>> latencyRequest = GC.requestLatency((long)2000)"*
>>
>> 2) Is there any test case description for Test.java ?
>>
>> 3) Will the GC run before the call manually *"GC.LatencyRequest
>> latencyRequest = GC.requestLatency((long)2000)"* ?
>>
>> 4) Also i have more memory , that shouldn't cause any overflow error.
>>
>> 5) Also by looking the bt, i can't trace main, GC, threads which are
>> running (total 4 threads. ) , Can you?
>
>
> First, tell us more about your Xtensa processor. What operating
> system is running on it? Is it Linux? If so, which distro?
>
>
> Thanks,
> Hinkmond
>
>
>>
>>
>> Expecting your co operation ,
>>
>>
>> /renjith g
>

[att1.html]

Renjith G

Also am getting a Caffeine score in the following range ,

Sieve score = 192 (98)
Loop score = 164 (2017)
Logic score = 202 (0)
String score = 890 (708)
Float score = 152 (185)
Method score = 173 (166650)
Overall score = 230

I dont know how to interpret this.

/renjith g

Renjith G wrote:
>
>
> Thanks Hinkmond
>
> This link will give you a brief idea about xtensa processors
> http://www.tensilica.com/uploads/pdf/xtensa_LX2_April07.pdf
>
> Also we are running linux in the board as the operating system and its
> flavor is * "Linux A2000 2.6.29-rc7**"
> *
>
> /renjith g*
> *
>
>
> Hinkmond Wong wrote:
>> Hi Renjith,
>>
>> Moving your questions over to the advanced@phoneme.dev.java.net mail
>> alias which is the proper forum for this type of question.
>>
>> Renjith G wrote:
>>> hi ,
>>>
>>> I have ported the phoneme JVM source code into our processor
>>> (Xtensa , core - C1LX2). But some problem has occurred when i run
>>> the Test.java above the ported JVM in my board.
>>>
>>> In the test suite(Test.java) , when we call *"testSunMiscGC()"*
>>> function and GC thread is invoked by
>>> "*GC.requestLatency((long)2000)" *(Assumption: GC thread comes into
>>> picture after 2 ms?),and then the thread goes to sleep for 5ms
>>> right? After this we cancels the latency request in the main thread(
>>> by *"latencyRequest.cancel()"* ). After this ,we call
>>> *"testManyFieldsAndMethods() "* and allocates a big memory in it. At
>>> this time the whole test crashed and thrown *signal 11*.
>>>
>>> When i put one sleep for 1ms after the *"latencyRequest.cancel()"*
>>> then the whole test become passed with out any problem. Also the
>>> whole test cases pass when we comment the *"testSunMiscGC()"*
>>>
>>>
>>> I debugged many times using the gdb at crash point. I am attaching
>>> the backtrace along with this mail.
>>>
>>> My assumption is that , the GC thread is still running and which
>>> caused the crash during the call "testManyFieldsAndMethods()" even
>>> after the request has been cancelled by calling
>>> *"latencyRequest.cancel()" *.
>>>
>>> Then my doubts:
>>>
>>> 1) For how long will the GC run when we call *"GC.LatencyRequest
>>> latencyRequest = GC.requestLatency((long)2000)"*
>>>
>>> 2) Is there any test case description for Test.java ?
>>>
>>> 3) Will the GC run before the call manually *"GC.LatencyRequest
>>> latencyRequest = GC.requestLatency((long)2000)"* ?
>>>
>>> 4) Also i have more memory , that shouldn't cause any overflow error.
>>>
>>> 5) Also by looking the bt, i can't trace main, GC, threads which
>>> are running (total 4 threads. ) , Can you?
>>
>>
>> First, tell us more about your Xtensa processor. What operating
>> system is running on it? Is it Linux? If so, which distro?
>>
>>
>> Thanks,
>> Hinkmond
>>
>>
>>>
>>>
>>> Expecting your co operation ,
>>>
>>>
>>> /renjith g
>>
>

[att1.html]