harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM][GC] I've made GCv5 the default GC
Date Thu, 10 May 2007 14:42:00 GMT
Alexey, thanks for the feedback on GCv5. It really needs this kind of
information to become robust.  Yes, with a parallel GC, sometimes the
breaks are very hard to reproduce. But the assert failure info given
below would always be useful.

Thanks,
xiaofeng

On 5/10/07, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> Sad to say, but gc_gen affected stability of DRLVM. There must be some
> data races in gcv5, it behaves unstably on heavily loaded 64-bit SMP
> boxes. A few examples:
> 1) Smoke test outofmemory.Double, WinServer2003@x64, debug OPT mode:
> Assertion failed: !next_block_for_dest, file
> C:\users\avarlamo\trunk\working_vm\vm\gc_gen\src\mark_compact\mspace_slide_compact.cpp,
> line 137
> 2) Automated EHWA, SLES9@x64, release default mode:
>
>      [echo]         ==================================
>      [echo]         Run Eclipse HelloWorld using Client mode JIT (default)
>      [echo]         ==================================
>      [echo]
>      [java] SIGSEGV in VM code.
>      [java] Stack trace:
>      [java]   0: gc_gen_adapt(GC_Gen*, long long) (??:-1)
>      [java]   1: pthread_mutex_unlock (??:-1)
>      [java]   2: apr_thread_mutex_unlock (locks/unix/thread_mutex.c:129)
>      [java]   3: apr_atomic_casptr (atomic/unix/apr_atomic.c:376)
>      [java]   4: ?? (??:-1)
>      [java]   5: ?? (??:-1)
>      [java]   6: gc_reclaim_heap(GC*, unsigned int) (??:-1)
>      [java]   7: fspace_alloc(unsigned int, Allocator*) (??:-1)
>      [java]   8: nos_alloc(unsigned int, Allocator*) (??:-1)
>      [java]   9: gc_alloc (??:-1)
>      [java]  10: vm_new_vector(Class*, int) (??:-1)
>      [java]  11: vm_multianewarray_recursive(Class*, int*, unsigned int) (??:-1)
>      [java]  12: ?? (??:-1)
>      [java]  13: vm_rt_multianewarray_recursive(Class*, int*, unsigned
> int) (??:-1)
>      [java]  14: rth_multianewarrayhelper() (??:-1)
>      [java]  15: exn_raised() (??:-1)
>      [java]  16: exn_rethrow_if_pending() (??:-1)
>      [java]  17: ?? (??:-1)
>      [java]  18: ?? (??:-1)
>      [java]  19:
> org/eclipse/jdt/core/compiler/CharOperation.splitOn(C[C)[[C
> (CharOperation.java:3080)
>      [java]  20:
> org/eclipse/jdt/internal/core/search/indexing/BinaryIndexer.extractReferenceFromConstantPool([BLorg/eclipse/jdt/internal/compiler/classfmt/ClassFileReader;)V
> (BinaryIndexer.java:601)
>      [java]  21:
> org/eclipse/jdt/internal/core/search/indexing/BinaryIndexer.indexDocument()V
> (BinaryIndexer.java:746)
>      [java]  22:
> org/eclipse/jdt/internal/core/search/JavaSearchParticipant.indexDocument(Lorg/eclipse/jdt/core/search/SearchDocument;Lorg/eclipse/core/runtime/IPath;)V
> (JavaSearchParticipant.java:74)
>      [java]  23:
> org/eclipse/jdt/internal/core/search/indexing/IndexManager.indexDocument(Lorg/eclipse/jdt/core/search/SearchDocument;Lorg/eclipse/jdt/core/search/SearchParticipant;Lorg/eclipse/jdt/internal/core/index/Index;Lorg/eclipse/core/runtime/IPath;)V
> (IndexManager.java:322)
>      [java]  24:
> org/eclipse/jdt/internal/core/search/indexing/AddJarFileToIndex.execute(Lorg/eclipse/core/runtime/IProgressMonitor;)Z
> (AddJarFileToIndex.java:197)
>      [java]  25:
> org/eclipse/jdt/internal/core/search/processing/JobManager.run()V
> (JobManager.java:372)
>      [java]  26: java/lang/Thread.run()V (Thread.java:661)
>      [java]  27: java/lang/Thread.runImpl()V (Thread.java:672)
>      [java] <end of stack trace>
>      [java] Java Result: 139
>
> 3) HARMONY-3767, SLES9@x64, classloader.StressLoader, gc.FinAlloc and
> sometimes perf.SeveralThreads hang in all 5 exec modes
>
> These are intermittent failures, and I've seen some others - but did
> not keep related logs. They are rare enough to complicate
> investigation (except the last JIRA), so I did not file issues for
> them.
>
> --
> Alexey
>
>
> 2007/5/8, Ivan Popov <ivan.g.popov@gmail.com>:
> > There is another problem with running JPDA unit tests on Linux SLES10.
> > I submitted https://issues.apache.org/jira/browse/HARMONY-3822
> >
> > Thanks.
> > Ivan
> >
> > On 5/7/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > > Thanks. Will check. -xiaofeng
> > >
> > > On 5/7/07, Ivan Popov <ivan.g.popov@gmail.com> wrote:
> > > > I submitted https://issues.apache.org/jira/browse/HARMONY-3820
> > > >
> > > > Thanks.
> > > > Ivan
> > > >
> > > > On 5/7/07, Ivan Popov <ivan.g.popov@gmail.com> wrote:
> > > > > I see many Eclipse TPTP profiler tests failed today after switching
> > > > > Harmony to GCv5. This failure needs deeper investigation, but at
the
> > > > > first glance it was caused by incorrect reporting JVMTI threads.
Also,
> > > > > I see strange threads list in Eclipse debugger. The "main" thread
> > > > > group now contains lot of "finalizer" threads and does not include
> > > > > "main" thread. Using gc_cc.dll solves this problem. I'm going to
> > > > > submit JIRA against GCv5.
> > > > >
> > > > > Thanks.
> > > > > Ivan
> > > > >
> > > > > PS:
> > > > > Threads reported by Eclipse debugger (using gc_gen):
> > > > >
> > > > >         HelloWorld at localhost:1067
> > > > >                 Thread Group [system]
> > > > >                         Thread Group [main]
> > > > >                                 Daemon Thread [ref handler] (Running)
> > > > >                                 Daemon Thread [finalizer] (Running)
> > > > >                                 Daemon Thread [finalizer] (Running)
> > > > >                                 Daemon Thread [finalizer] (Running)
> > > > >                                 Daemon Thread [finalizer] (Running)
> > > > >                                 Daemon Thread [finalizer] (Running)
> > > > >                                 Daemon Thread [finalizer] (Running)
> > > > >                                 Daemon Thread [finalizer] (Running)
> > > > >                                 Daemon Thread [finalizer] (Running)
> > > > >
> > > > > Threads reported by Eclipse debugger (using gc_cc.dll)
> > > > >
> > > > >         HelloWorld at localhost:1045
> > > > >                 Thread Group [system]
> > > > >                         Daemon System Thread [FinalizerThread] (Running)
> > > > >                         Thread Group [main]
> > > > >                                 Thread [main] (Suspended (breakpoint
at line 5 in HelloWorld))
> > > > >                                         HelloWorld.main(String[])
line: 5
> > > > >
> > > > >
> > > > > On 5/6/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > > > > > Hi, folks, I've switched GCv5 to be the default GC. In today's
> > > > > > CruiseControl tests with GCv5, shown at
> > > > > > http://www.harmonytest.org/upload/cc2.html, we can see all tests
> > > > > > passed. I known there are still potential bugs, we fix them
once
> > > > > > exposed.
> > > > > >
> > > > > > If you have some workloads having problem with GCv5, please
try GCv4.1
> > > > > > with command option -XX:vm.dlls=gc_cc.dll . At the moment, there
are
> > > > > > two known issues, one is the intermittent failure with kernel.test
> > > > > > java.langThreadTest; the other is that it has currently minimum
256MB
> > > > > > heap size. The former one is hard to reproduce, the second one
is easy
> > > > > > to fix. Welcome feedbacks and suggestions. Thanks.
> > > > > >
> > > > > > There are still lots of work to do to make Harmony GC close
to be
> > > > > > perfect. To switch from GCv4.1 to GCv5 is only one step towards
the
> > > > > > goal, well it is an important step in my opinion. Next step,
besides
> > > > > > continuing GCv5 polishment, is to develop a low-pause-time GC.
I will
> > > > > > post a high level design soon.
> > > > > >
> > > > > > Thanks,
> > > > > > xiaofeng
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > http://xiao-feng.blogspot.com
> > >
> >
>


-- 
http://xiao-feng.blogspot.com

Mime
View raw message