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, [EMAIL PROTECTED], 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, [EMAIL PROTECTED], 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, [EMAIL PROTECTED], 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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]> wrote:
> Thanks. Will check. -xiaofeng
>
> On 5/7/07, Ivan Popov <[EMAIL PROTECTED]> wrote:
> > I submitted https://issues.apache.org/jira/browse/HARMONY-3820
> >
> > Thanks.
> > Ivan
> >
> > On 5/7/07, Ivan Popov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>
