harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [DRLVM][GC] I've made GCv5 the default GC
Date Thu, 10 May 2007 09:48:42 GMT
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
> >
>

Mime
View raw message