harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [general] Reminder: stable build goal at end of month
Date Wed, 18 Apr 2007 08:41:20 GMT
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