harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ivanov" <ivavladi...@gmail.com>
Subject Re: [general] Reminder: stable build goal at end of month
Date Wed, 18 Apr 2007 08:51:41 GMT
On 4/18/07, Xiao-Feng Li <xiaofeng.li@gmail.com> 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. :-)

Excellent! In this case I vote to use GCv5 by default.
 thanks, Vladimir

PS I did not test it on Win x86_64, but I hope it will work OK.

>
> Thanks,
> xiaofeng
>
> On 4/18/07, Vladimir Ivanov <ivavladimir@gmail.com> 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 <alexey.a.petrenko@gmail.com> 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 <rdasgupt@gmail.com>:
> > > > 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 <mike.fursov@gmail.com> 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 <xiaofeng.li@gmail.com> wrote:
> > > > > >
> > > > > > On 4/18/07, Mikhail Loenko <mloenko@gmail.com> 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 <xiaofeng.li@gmail.com>:
> > > > > > > > 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 <t.p.ellison@gmail.com>
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
>

Mime
View raw message