harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm][x86_64] status update
Date Fri, 17 Nov 2006 19:27:34 GMT
I was hoping you wouldn't say that.

Time to modify the DRLVM build for testing.

<sob>

geir


Pavel Afremov wrote:
> 
> 
> On 11/17/06, *Geir Magnusson Jr.* <geir@pobox.com 
> <mailto:geir@pobox.com>> wrote:
> 
>     I'm happy to disable tests.
> 
>     I was disappointed in 2224 - I assumed that it was an external "exclude
>     list" :)
> 
>     But I guess that works.  How do we exclude for more than 1 platform?
> 
>  
> 
> It's impossible, as I understand.
> 
>  
> 
> Pavel Afremov
> 
> 
>     geir
> 
> 
>     Rana Dasgupta wrote:
>      > Hi,
>      >   Sadly, I still run or debug any of this yet. But my suggestion and
>      > request would be that we commit Pavel's patch 2224 which for now
>     disables
>      > the overfow tests on EM64T. That would give us some time to
>     understand and
>      > debug the problem. We are good on 32 bit.
>      >   The bottom line is that the main thread stack growth and mapping
>      > behaviour and guard paging seems to vary across Linux
>     implementations,
>      > specially between older and more current implementations. Some
>     behaviour
>      > could also be specific to SUSE. We will figure out what is the
>     best and
>      > broadest solution.
>      >
>      > Thanks,
>      > Rana
>      >
>      > On 11/17/06, Pavel Afremov <pavel.n.afremov@gmail.com
>     <mailto:pavel.n.afremov@gmail.com>> wrote:
>      >>
>      >>
>      >>
>      >>
>      >>
>      >> Yes, of cause... partially :)
>      >>
>      >> 1) mprotect can't work on main application thread without mmap. Rana
>      >> found
>      >> out this fact. I think I can explain it, but it is guess only. I
>     can't
>      >> find
>      >> description of it in google... Also on different versions of Linux
>      >> behavior
>      >> is different.
>      >>
>      >> 2) Rana implemented call of mmap for protected page to call
>     mprotect for
>      >> it.
>      >> But it's not enough on some Linux. On my machines sigsegv
>     happened one
>      >> page
>      >> before guard page in this case. I suppose that OS check next
>     page status
>      >> before allocate requested page for the stack. And if next page
>     is already
>      >> mmapped - OS decides that stack can't grow and sigsegv is happened.
>      >> Theoretically stack of the thread can grow infinitely especially
>     on EM64T
>      >> platform.
>      >>
>      >> 3) I checked mapped areas for the debugged VM and found, that
>     for others
>      >> threads, not main thread, whole stack mapped at once. So I tried
>     to map
>      >> whole stack for main thread in the beginning of the work, at
>     once. And it
>      >> works.
>      >>
>      >>
>      >>
>      >> Thanks
>      >> Pavel Afremov.
>      >>
>      >> >
>      >> > > But  gc.Force and others became fail. The source, as I
>     understand, is
>      >> in
>      >> > > following: after mmap of   the stack, java method
>     Object.wait() can't
>      >> > > works.  SuSE 10 hangs up, SuSE 9 makes exit on it
>      >> > >
>      >> > >
>      >> >
>      >> > I'm just marveling over the fact you got gdb to work.  Can
>     anyone else
>      >> > w/ Ubunutu 32-bit or 64-bit debug drlvm in a reasonable way?
>      >> >
>      >> >
>      >> > >
>      >> > > Gdb shows sigsegv in
>      >> > >
>      >> > > #0  0x0000002a961d489d in pthread_cond_wait@@GLIBC_2.3.2 ()
>     from
>      >> > > /lib64/tls/libpthread.so.0
>      >> > >
>      >> > > #1  0x0000002a957a7501 in apr_thread_cond_wait
>     (cond=Variable "cond"
>      >> is
>      >> > > not available.)
>      >> > >
>      >> > >     at thread_cond.c:68
>      >> > >
>      >> > > #2  0x0000002a957a3e85 in condvar_wait_impl (cond=0x2aaa309778,
>      >> > > mutex=0x2aaa309728, ms=0, nano=0, interruptable=1)
>      >> > >
>      >> > >     at
>      >> > >
>      >> >
>      >>
>     /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_condvar.c:69
>      >>
>      >> > >
>      >> > >
>      >> > > #3  0x0000002a957a4463 in monitor_wait_impl
>     (mon_ptr=0x2aaa3096c8,
>      >> ms=0,
>      >> > > nano=0, interruptable=1)
>      >> > >
>      >> > >     at
>      >> > >
>      >> >
>      >>
>     /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_fat_monitor.c:208
>      >>
>      >> > >
>      >> > >
>      >> > > #4  0x0000002a957a652b in thin_monitor_wait_impl
>      >> > > (lockword_ptr=0x2a98c24e54, ms=0, nano=0, interruptable=1)
>      >> > >
>      >> > >     at
>      >> > >
>      >> >
>      >>
>     /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_thin_monitor.c:430
> 
>      >>
>      >> > >
>      >> > >
>      >> > > #5  0x0000002a957a65b1 in
>     hythread_thin_monitor_wait_interruptable
>      >> > > (lockword_ptr=0x2a98c24e54, ms=0, nano=0)
>      >> > >
>      >> > >     at
>      >> > >
>      >> >
>      >>
>     /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_native_thin_monitor.c:482
>      >>
>      >> > >
>      >> > >
>      >> > > #6  0x0000002a96b97f15 in jthread_monitor_timed_wait
>      >> > > (monitor=0x7fbfffcbc8, millis=0, nanos=0)
>      >> > >
>      >> > >     at
>      >> > >
>      >> >
>      >>
>     /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/thread/src/thread_java_monitors.c:337
>      >>
>      >> > >
>      >> > >
>      >> > > #7  0x0000002a96a29a08 in Java_java_lang_VMThreadManager_wait
>      >> > > (env=0x594c58, clazz=0x7fbfffcbc0, monitor=0x7fbfffcbc8,
>     millis=0,
>      >> > nanos=0)
>      >> > >
>      >> > >     at
>      >> > >
>      >> >
>      >>
>     /nfs/ims/proj/drl/mrt1/users/pnafremo/work/PBBC_64/drlvm/vm/vmcore/src/kernel_classes/native/java_lang_VMThreadManager.cpp:202
> 
>      >>
>      >> > >
>      >> > >
>      >> > >
>      >> > >
>      >> > > In HARMONY-2224
>      >> <https://issues.apache.org/jira/browse/HARMONY-2224
>     <https://issues.apache.org/jira/browse/HARMONY-2224>> I
>      >> > > excluded failed tests from acceptance test set:
>      >> > >
>      >> > >     StackTest & exception.FinalizerStackTest on EM64T
>      >> > >
>      >> > >     gc.LOS on Windows.
>      >> > >
>      >> >
>      >> > I'll go check this out immediately
>      >> >
>      >> > geir
>      >> >
>      >> > >
>      >> > > BR.
>      >> > > Pavel Afremov
>      >> > >
>      >> > >
>      >> > > On 11/17/06, *Geir Magnusson Jr.* <geir@pobox.com
>     <mailto:geir@pobox.com>
>      >> > > <mailto: geir@pobox.com <mailto:geir@pobox.com>>>
wrote:
>      >> > >
>      >> > >
>      >> > >
>      >> > >     Rana Dasgupta wrote:
>      >> > >      > Not surprising :-) The last big stack relatad checkin
>     in 2018.
>      >> > >     Its comment
>      >> > >      > notes say that Gregory actually saw the failure of
>     StackTest
>      >> and
>      >> > >     the new
>      >> > >      > FinalizeStackTest...
>      >> > >
>      >> > >     So... lets fix them... :)
>      >> > >
>      >> > >     geir
>      >> > >
>      >> > >      >
>      >> > >      > On 11/16/06, Geir Magnusson Jr. < geir@pobox.com
>     <mailto:geir@pobox.com>
>      >> > >     <mailto:geir@pobox.com <mailto:geir@pobox.com>>>
wrote:
>      >> > >      >>
>      >> > >      >> First test that fails is the most cherished and
beloved
>      >> > >     StackTest, with
>      >> > >      >> a segmentation fault :)
>      >> > >      >>
>      >> > >      >> I'll try to find some more useful info...
>      >> > >      >>
>      >> > >      >> geir
>      >> > >      >>
>      >> > >      >>
>      >> > >      >> Geir Magnusson Jr. wrote:
>      >> > >      >> > We now have DRLVM+Classlib cleanly building
out of
>     SVN and
>      >> > >     able to run
>      >> > >      >> > basic programs on Ubuntu 6 on an em64T box.
>      >> > >      >> >
>      >> > >      >> > $ uname -a  :
>      >> > >      >> >
>      >> > >      >> > Linux harmony-em64t 2.6.15-27-amd64-generic
#1 SMP
>     PREEMPT
>      >> Sat
>      >> > >     Sep 16
>      >> > >      >> > 01:50:50 UTC 2006 x86_64 GNU/Linux
>      >> > >      >> >
>      >> > >      >> > Now starting to look into the test suite.
 Tests are
>      >> passing,
>      >> > >     but I've
>      >> > >      >> > just started...
>      >> > >      >> >
>      >> > >      >> > Well done, everyone!
>      >> > >      >> >
>      >> > >      >> > geir
>      >> > >      >> >
>      >> > >      >>
>      >> > >      >
>      >> > >
>      >> > >
>      >> >
>      >>
>      >>
>      >
> 
> 

Mime
View raw message