harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [general] Reminder: stable build goal at end of month
Date Wed, 18 Apr 2007 09:06:35 GMT
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

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
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>

Mime
View raw message