You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Xiao-Feng Li <xi...@gmail.com> on 2007/05/06 14:24:43 UTC
[DRLVM][GC] I've made GCv5 the default GC
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
Re: [DRLVM][GC] I've made GCv5 the default GC
Posted by Ivan Popov <iv...@gmail.com>.
There is one more problem with running several DRLVM instances with
GCv5 on a weak machine, which is currently used for CruiseControl
runs. This breaks jdk_tools CC results. I've found existing
HARMONY-3756 and provided details there.
Thanks.
Ivan
On 5/8/07, Ivan Popov <iv...@gmail.com> wrote:
> 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 <xi...@gmail.com> wrote:
> > Thanks. Will check. -xiaofeng
> >
> > On 5/7/07, Ivan Popov <iv...@gmail.com> wrote:
> > > I submitted https://issues.apache.org/jira/browse/HARMONY-3820
> > >
> > > Thanks.
> > > Ivan
> > >
> > > On 5/7/07, Ivan Popov <iv...@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 <xi...@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
> >
>
Re: [DRLVM][GC] I've made GCv5 the default GC
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <al...@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 <iv...@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 <xi...@gmail.com> wrote:
> > > Thanks. Will check. -xiaofeng
> > >
> > > On 5/7/07, Ivan Popov <iv...@gmail.com> wrote:
> > > > I submitted https://issues.apache.org/jira/browse/HARMONY-3820
> > > >
> > > > Thanks.
> > > > Ivan
> > > >
> > > > On 5/7/07, Ivan Popov <iv...@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 <xi...@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
Re: [DRLVM][GC] I've made GCv5 the default GC
Posted by Alexey Varlamov <al...@gmail.com>.
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 <iv...@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 <xi...@gmail.com> wrote:
> > Thanks. Will check. -xiaofeng
> >
> > On 5/7/07, Ivan Popov <iv...@gmail.com> wrote:
> > > I submitted https://issues.apache.org/jira/browse/HARMONY-3820
> > >
> > > Thanks.
> > > Ivan
> > >
> > > On 5/7/07, Ivan Popov <iv...@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 <xi...@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
> >
>
Re: [DRLVM][GC] I've made GCv5 the default GC
Posted by Ivan Popov <iv...@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 <xi...@gmail.com> wrote:
> Thanks. Will check. -xiaofeng
>
> On 5/7/07, Ivan Popov <iv...@gmail.com> wrote:
> > I submitted https://issues.apache.org/jira/browse/HARMONY-3820
> >
> > Thanks.
> > Ivan
> >
> > On 5/7/07, Ivan Popov <iv...@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 <xi...@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
>
Re: [DRLVM][GC] I've made GCv5 the default GC
Posted by Xiao-Feng Li <xi...@gmail.com>.
Thanks. Will check. -xiaofeng
On 5/7/07, Ivan Popov <iv...@gmail.com> wrote:
> I submitted https://issues.apache.org/jira/browse/HARMONY-3820
>
> Thanks.
> Ivan
>
> On 5/7/07, Ivan Popov <iv...@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 <xi...@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
Re: [DRLVM][GC] I've made GCv5 the default GC
Posted by Ivan Popov <iv...@gmail.com>.
I submitted https://issues.apache.org/jira/browse/HARMONY-3820
Thanks.
Ivan
On 5/7/07, Ivan Popov <iv...@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 <xi...@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
> >
>
Re: [DRLVM][GC] I've made GCv5 the default GC
Posted by Ivan Popov <iv...@gmail.com>.
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 <xi...@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
>