harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: [general] Reminder: stable build goal at end of month
Date Thu, 19 Apr 2007 05:12:56 GMT
On 4/18/07, Mikhail Loenko 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
>

Minor suggestion: can we stop committing any updates before switching
to GCv5? Otherswise it may be hard to understand why tests fails. As I
understand 5~6 hours is enough for CC to do full testing cycle. So we
can let CC finish testing cycle with old GC, do switch and see whether
tests pass or not with new GC.

Thanks,
Stepan.

> Thanks,
> Mikhail
>
> 2007/4/18, Tim Ellison <t.p.ellison@gmail.com>:
> > 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 <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
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>


-- 
Stepan Mishura
Intel Enterprise Solutions Software Division

Mime
View raw message