On 4/18/07, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
Let's wait until the patch from Xiao-Feng is integrated, and if failures disappear and no new failures appear, let's switch our default
Right, this is also what I think. :-) Thanks, xiaofeng
Thanks, Mikhail 2007/4/18, Tim Ellison <[EMAIL PROTECTED]>: > So how about we switch to GCv5 today as the default? If things look > good then we are all happy, and if new problems are immediately apparent > we drop back to Old Faithful. > > Best that we get everyone testing on the proposed code asap. Of course, > anything that misses this milestone can be a candidate for the next > (which we haven't discussed yet, but IMHO should be in 6-8 weeks time > after M1). It is not a full release. > > Regards, > Tim > > Xiao-Feng Li wrote: > > Vladimir, thanks, this is what I observed as well. They are coming > > from a same bug, and the patch will be submitted in one or two hours, > > so I don't worry about it. :-) > > > > Thanks, > > xiaofeng > > > > On 4/18/07, Vladimir Ivanov <[EMAIL PROTECTED]> wrote: > >> It is just my statistics: > >> > >> WinXP, ia32: > >> Classlib tests: passed > >> DRLVM tests (int+jet+jit+opt modes): list of failed tests: > >> java.lang.reflect.Ctor5Test; > >> java.lang.reflect.Field5Test; > >> java.lang.reflect.Method5Test; > >> java.lang.ThreadTest; > >> org.apache.harmony.lang.annotation.AllTypesTest > >> > >> Linux, ia32: > >> Classlib tests: java.awt.font.LineBreakMeasurerTest failed > >> DRLVM tests (int+jet+jit+opt modes): list of failed tests: > >> java.lang.ThrowableTest – hang (int mode) > >> java.lang.reflect.Ctor5Test; > >> java.lang.reflect.Field5Test; > >> java.lang.reflect.Method5Test; > >> java.lang.ThreadTest; > >> org.apache.harmony.lang.annotation.AllTypesTest > >> > >> Linux, em64t: > >> Classlib tests: list of failed tests > >> java.awt.CanvasRTest – hang > >> javax.swing.plaf.basic.BasicListUITest - hang > >> javax.swing.JSliderTest > >> javax.swing.JTableRTest > >> javax.swing.plaf.basic.BasicFileChooserUITest > >> javax.swing.plaf.basic.BasicFormattedTextFieldUITest > >> javax.swing.plaf.basic.BasicIconFactoryTest > >> > >> DRLVM tests (int+jet+jit+opt modes): list of failed tests: > >> java.lang.reflect.Ctor5Test; > >> java.lang.reflect.Field5Test; > >> java.lang.reflect.Method5Test; > >> java.lang.ThreadTest; > >> org.apache.harmony.lang.annotation.AllTypesTest > >> and > >> All JVMTI tests using interpreter > >> ------------- > >> SIGSEGV in VM code. > >> Stack trace: > >> 0: jthread_monitor_enter > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/thread/src/thread_java_monitors.c:145) > >> > >> 1: vm_monitor_enter_default > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/vmcore/src/thread/mon_enter_exit.cpp:115) > >> > >> 2: vm_monitor_enter_wrapper(ManagedObject*) > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/vmcore/src/interpreter/interp_imports.cpp:30) > >> > >> 3: Opcode_MONITORENTER(StackFrame&) > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/interpreter/src/interpreter.cpp:2277) > >> > >> 4: > >> org/apache/harmony/fortress/security/SecurityUtils.putContext(Ljava/lang/Thread;Ljava/security/AccessControlContext;)V > >> > >> (SecurityUtils.java:76) > >> 5: interpreterInvokeStatic > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/interpreter/src/interpreter.cpp:3318) > >> > >> 6: Opcode_INVOKESTATIC(StackFrame&) > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/interpreter/src/interpreter.cpp:2105) > >> > >> 7: > >> java/lang/Thread.<init>(Ljava/lang/ThreadGroup;Ljava/lang/String;JJIZ)V > >> (Thread.java:253) > >> 8: interpreter_execute_method(Method*, jvalue*, jvalue*) > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/interpreter/src/interpreter.cpp:3211) > >> > >> 9: JIT_execute_method > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/interpreter/src/interp_exports.cpp:167) > >> > >> 10: DrlEMImpl::executeMethod(_jmethodID*, jvalue*, jvalue*) > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/em/src/DrlEMImpl.cpp:510) > >> > >> 11: ExecuteMethod > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/em/src/em_intf.cpp:44) > >> 12: vm_execute_java_method_array(_jmethodID*, jvalue*, jvalue*) > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/vmcore/src/jit/ini.cpp:56) > >> > >> 13: vm_create_jthread > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/vmcore/src/init/vm_init.cpp:560) > >> > >> 14: vm_attach_internal(JNIEnv_External**, _jobject**, > >> JavaVM_External*, _jobject*, char*, unsigned char) > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/vmcore/src/init/vm_init.cpp:601) > >> > >> 15: attach_current_thread > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/vmcore/src/jni/jni.cpp:1519) > >> > >> 16: AttachCurrentThreadAsDaemon(JavaVM_External*, void**, void*) > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/vmcore/src/jni/jni.cpp:1548) > >> > >> 17: finalizer_thread_func > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/vmcore/src/init/finalizer_thread.cpp:204) > >> > >> 18: thread_start_proc > >> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/thread/src/thread_native_basic.c:716) > >> > >> 19: start_thread (??:-1) > >> <end of stack trace> > >> ------------- > >> > >> thanks, Vladimir > >> > >> On 4/18/07, Alexey Petrenko <[EMAIL PROTECTED]> wrote: > >> > I think that we make GCv5 default a week before the milestone since it > >> > gives us some benefits. > >> > And if we discover any stability or other issues we always can switch > >> > it back before the milestone. > >> > > >> > SY, Alexey > >> > > >> > 2007/4/18, Rana Dasgupta <[EMAIL PROTECTED]>: > >> > > In addition to specs and eclipse, there are the tests that come with > >> > > "build test". Are there any more tests we are worried about? > >> > > > >> > > I understand the risk of switching before an event, but we will have > >> > > to do it at some point. Not much point in writing it and then not > >> > > using it. Doing it still gives us a few weeks before Java One to see > >> > > if there are problems. How about running it as default for a week > >> > > before we decide? > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > On 4/17/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > >> > > > It's quite risky to switch right before the show. > >> > > > Xiao-Feng, what workloads you tried with gcv5 except specs and > >> eclipse? > >> > > > > >> > > > + > >> > > > I'm working on "lazy resolution" task in both JITs now and going > >> to submit > >> > > > the patch this week for > >> > > > review. I think its commit should be delayed for a few weeks until > >> > > > JavaOne is finished. > >> > > > > >> > > > > >> > > > On 4/18/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > >> > > > > > >> > > > > On 4/18/07, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > >> > > > > > Do you think we should switch before "end of month"? > >> > > > > > >> > > > > Yes, that's my suggestion. > >> > > > > > >> > > > > > It's certainly a risk, but what is the value in the switch? > >> > > > > > >> > > > > The risk is minimal since GCv5 is rather stable, and to the > >> least we > >> > > > > have command line option to switch back; but the value is > >> substantial > >> > > > > since people can have an advanced, scalable, modular, > >> flexible, high > >> > > > > performance GC, which I think both runtime researchers and > >> users would > >> > > > > like to try, based on my interactions with Harmony users. > >> > > > > > >> > > > > To demo Harmony, GC is one component that we'd like to have a > >> good > >> > > > > story to tell. GCv5 can tell a good story since it has > >> subsumed almore > >> > > > > all the recent advances in GC area (for stop-the-world GC), > >> and has a > >> > > > > variable of innovations. Importantly, GCv5 can differentiate > >> > > > > multi-core platforms with its scalable parallelisms. :-) > >> > > > > > >> > > > > Thanks, > >> > > > > xiaofeng > >> > > > > > >> > > > > > Thanks, > >> > > > > > Mikhail > >> > > > > > > >> > > > > > 2007/4/18, Xiao-Feng Li <[EMAIL PROTECTED]>: > >> > > > > > > GCv5 might be one "major" that we want to put as default > >> GC in DRLVM. > >> > > > > > > It still has some issues pending, but overall I think the > >> stability is > >> > > > > > > good enough for a switch next week. > >> > > > > > > > >> > > > > > > Since GC is designed with good modularity, we can simply > >> choose which > >> > > > > > > GC implementation to use in command line with > >> > > > > > > '-XX:vm.dlls=the_gc_module.dll(so)". This is neat that > >> helps the > >> > > > > > > switch a lot: If GCv5 has some problem running a workload, > >> we can > >> > > > > > > specify -XX:vm.dlls=gc_cc.dll in command line. > >> > > > > > > > >> > > > > > > So far the known bugs in GCv5 are not with some workloads, > >> but related > >> > > > > > > with certain test cases for finalizer and VM threading. > >> And I think > >> > > > > > > they are going to be resolved before next week. > >> > > > > > > > >> > > > > > > Thanks, > >> > > > > > > xiaofeng > >> > > > > > > > >> > > > > > > On 4/16/07, Tim Ellison <[EMAIL PROTECTED]> wrote: > >> > > > > > > > Just a reminder, as discussed in various threads, we > >> shall aim to > >> > > > > > > > produce a solid build for Windows and Linux x86 (at > >> least) at the > >> > > > > end of > >> > > > > > > > next week; so that we have something to demo at > >> ApacheCon and > >> > > > > JavaOne > >> > > > > > > > that is a true reflection of our current capabilities. > >> > > > > > > > > >> > > > > > > > Of course, the Milestone will be simply a snapshot, > >> carrying our > >> > > > > usual > >> > > > > > > > caveats. The idea is that with conference talks taking > >> place we may > >> > > > > > > > expect a few people to download a build and try it > >> around that time, > >> > > > > so > >> > > > > > > > being in the middle of a major restructuring would > >> potentially do us > >> > > > > an > >> > > > > > > > injustice. > >> > > > > > > > > >> > > > > > > > Most commits still seem to be on-going bug fixing, so > >> that's all > >> > > > > > > > goodness. If you are planning on anything 'major' > >> please ensure > >> > > > > there > >> > > > > > > > is enough time to get it stable, or please wait until > >> after the > >> > > > > > > > milestone build. Similarly, if there is anything that > >> is currently > >> > > > > > > > 'broken' that you think really needs fixing for that > >> stability, > >> > > > > please > >> > > > > > > > shout here on the list. > >> > > > > > > > > >> > > > > > > > There are still two weeks to go, I think the paranoia > >> about not > >> > > > > causing > >> > > > > > > > regressions will really kick-in next week :-) > >> > > > > > > > > >> > > > > > > > Regards, > >> > > > > > > > Tim > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > -- > >> > > > > > > http://xiao-feng.blogspot.com > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > -- > >> > > > > http://xiao-feng.blogspot.com > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Mikhail Fursov > >> > > > > >> > > > >> > > >> > > > > >
-- http://xiao-feng.blogspot.com
