Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of liyilei1979@gmail.com
 designates 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=gA7T0lo7sjhSeWv6tAWxIehd79bsa+BkZSBDjNBT2Zx+SMIhBWryZAGG2cMHl8o2Rfb/5/Q14XJa2DYIVFTDJwjbT/uXaWr7ViiF0D9+LkkOqr9ZUmdirjlMExqwzbI6vagXAIUkw/UGFOw7Y2+X6BmIlW6ZlGDJLoGA4oLQ2Vo=
Message-ID: <e66844de0704190000j4912c2bhc83d2feb61441c8e@mail.gmail.com>
Date: Thu, 19 Apr 2007 15:00:41 +0800
From: "Leo Li" <liyilei1979@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [general] Reminder: stable build goal at end of month
In-Reply-To: <c3755b3a0704182236h26a1229cld40d62c7bfae057@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_64798_23536683.1176966041341"
References: <46234649.2070100@gmail.com>
	 <bc79dd600704172011g717d9e29hee75dd4de2e7fef2@mail.gmail.com>
	 <51d555c70704172055x759b4e59i7dc377df65af8b13@mail.gmail.com>
	 <c3755b3a0704172345j110422f6k7bccf9a5e5c25d54@mail.gmail.com>
	 <7273946b0704180104x7bd04c6av8d625b02a0e5df19@mail.gmail.com>
	 <9623c9a50704180120i78abb501gb870ed85db0c8fbc@mail.gmail.com>
	 <4625D9B0.4060706@gmail.com>
	 <906dd82e0704180206h3c3f6d5as9200b483577e863b@mail.gmail.com>
	 <6e47b64f0704182212w5beab498rb8b176e674cdd90e@mail.gmail.com>
	 <c3755b3a0704182236h26a1229cld40d62c7bfae057@mail.gmail.com>

------=_Part_64798_23536683.1176966041341
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

 Waiting to see...
 A new GC, with enhanced performance and stable behavior.:)


On 4/19/07, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
>
> No objections from me.
> When we plan to switch to GCv5?
>
> SY, Alexey
>
> 2007/4/19, Stepan Mishura <stepan.mishura@gmail.com>:
> > 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 loo=
k
> > > > 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 comin=
g
> > > > > 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 =96 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 =96 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_m=
onitors.c:145)
> > > > >>
> > > > >>   1: vm_monitor_enter_default
> > > > >>
> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/vmcore/src/thread/mon_en=
ter_exit.cpp:115)
> > > > >>
> > > > >>   2: vm_monitor_enter_wrapper(ManagedObject*)
> > > > >>
> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/vmcore/src/interpreter/i=
nterp_imports.cpp:30)
> > > > >>
> > > > >>   3: Opcode_MONITORENTER(StackFrame&)
> > > > >>
> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/interpreter/src/interpre=
ter.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/interpre=
ter.cpp:3318)
> > > > >>
> > > > >>   6: Opcode_INVOKESTATIC(StackFrame&)
> > > > >>
> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/interpreter/src/interpre=
ter.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/interpre=
ter.cpp:3211)
> > > > >>
> > > > >>   9: JIT_execute_method
> > > > >>
> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/interpreter/src/interp_e=
xports.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:5=
6)
> > > > >>
> > > > >>  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:1=
519)
> > > > >>
> > > > >>  16: AttachCurrentThreadAsDaemon(JavaVM_External*, void**, void*=
)
> > > > >>
> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/vmcore/src/jni/jni.cpp:1=
548)
> > > > >>
> > > > >>  17: finalizer_thread_func
> > > > >>
> (/export/cruise/trunk/cc/projects/drlvm/trunk/vm/vmcore/src/init/finalize=
r_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 the=
n
> not
> > > > >> > > using it. Doing it still gives us a few weeks before Java On=
e
> 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 i=
s
> > > > >> 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 thin=
k
> 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=3Dthe_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=3Dgc_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 (a=
t
> > > > >> 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
> >
>


--=20
Leo Li
China Software Development Lab, IBM

------=_Part_64798_23536683.1176966041341--