You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2007/04/16 11:47:53 UTC
[general] Reminder: stable build goal at end of month
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
Re: [general] Reminder: stable build goal at end of month
Posted by Alexei Fedotov <al...@gmail.com>.
Hello,
I have fixed help in Eclipse 3.3 (actually it was a problem in marking
jetty class subroutine):
https://issues.apache.org/jira/browse/HARMONY-3725
The help works now, and it may be useful for demo.
On 4/16/07, Tim Ellison <t....@gmail.com> wrote:
> Alexei Fedotov wrote:
> > Which VM (DRLVM or J9) do you plan to use in your demo? The intention
> > of my question is to understand if your suggestion applies to DRLVM
> > code.
>
> DRLVM -- a full-on Harmony demo. The apps to demo will depend upon
> which ones work^w demo well.
>
> Regards,
> Tim
>
--
With best regards,
Alexei,
ESSD, Intel
Re: [general] Reminder: stable build goal at end of month
Posted by Tim Ellison <t....@gmail.com>.
Alexei Fedotov wrote:
> Which VM (DRLVM or J9) do you plan to use in your demo? The intention
> of my question is to understand if your suggestion applies to DRLVM
> code.
DRLVM -- a full-on Harmony demo. The apps to demo will depend upon
which ones work^w demo well.
Regards,
Tim
Re: [general] Reminder: stable build goal at end of month
Posted by Alexei Fedotov <al...@gmail.com>.
Tim,
Which VM (DRLVM or J9) do you plan to use in your demo? The intention
of my question is to understand if your suggestion applies to DRLVM
code.
Thank you.
On 4/16/07, Tim Ellison <t....@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
>
--
With best regards,
Alexei,
ESSD, Intel
Re: [general] Reminder: stable build goal at end of month
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/18/07, Alexey Varlamov <al...@gmail.com> wrote:
>
> I'm going to integrate finally HARMONY-3291 (Fast TLS access on Linux
> (IA32&Intel64), hopefully today. Actually this is not a threading
> issue, it affects JIT mainly. No stability risk, it either works or
> not.
>
> +1 here. This patch is about 2 monthes old and there were never problems
with it.
--
Mikhail Fursov
Re: [general] Reminder: stable build goal at end of month
Posted by Alexey Varlamov <al...@gmail.com>.
I'm going to integrate finally HARMONY-3291 (Fast TLS access on Linux
(IA32&Intel64), hopefully today. Actually this is not a threading
issue, it affects JIT mainly. No stability risk, it either works or
not.
2007/4/18, Weldon Washburn <we...@gmail.com>:
> On 4/17/07, Tim Ellison <t....@gmail.com> wrote:
> >
> > Rana Dasgupta wrote:
> > > Are all the threading changes Weldon and Co. are in the process of
> > > making going to make it by next week?
> > >
> > > If not, should we freeze threading changes till the snapshot is done?
> > > Weldon?
>
>
> Most likely the above is what we will end up doing. There is still a small
> chance that we will commit a patch before May 1 that addresses the "memory
> leak when a thread dies" problem.
>
> Weldon said in [1] there is way more work than we can do (and get
> > stable) for this milestone; so yes I expect some will have to be
> > deferred until after that.
>
>
>
> [1] http://article.gmane.org/gmane.comp.java.harmony.devel/25458
> >
> > Regards,
> > Tim
> >
>
>
>
> --
> Weldon Washburn
>
Re: [general] Reminder: stable build goal at end of month
Posted by Weldon Washburn <we...@gmail.com>.
On 4/17/07, Tim Ellison <t....@gmail.com> wrote:
>
> Rana Dasgupta wrote:
> > Are all the threading changes Weldon and Co. are in the process of
> > making going to make it by next week?
> >
> > If not, should we freeze threading changes till the snapshot is done?
> > Weldon?
Most likely the above is what we will end up doing. There is still a small
chance that we will commit a patch before May 1 that addresses the "memory
leak when a thread dies" problem.
Weldon said in [1] there is way more work than we can do (and get
> stable) for this milestone; so yes I expect some will have to be
> deferred until after that.
[1] http://article.gmane.org/gmane.comp.java.harmony.devel/25458
>
> Regards,
> Tim
>
--
Weldon Washburn
Re: [general] Reminder: stable build goal at end of month
Posted by Tim Ellison <t....@gmail.com>.
Rana Dasgupta wrote:
> Are all the threading changes Weldon and Co. are in the process of
> making going to make it by next week?
>
> If not, should we freeze threading changes till the snapshot is done?
> Weldon?
Weldon said in [1] there is way more work than we can do (and get
stable) for this milestone; so yes I expect some will have to be
deferred until after that.
[1] http://article.gmane.org/gmane.comp.java.harmony.devel/25458
Regards,
Tim
Re: [general] Reminder: stable build goal at end of month
Posted by Rana Dasgupta <rd...@gmail.com>.
Are all the threading changes Weldon and Co. are in the process of
making going to make it by next week?
If not, should we freeze threading changes till the snapshot is done? Weldon?
On 4/16/07, Tim Ellison <t....@gmail.com> wrote:
> Mikhail Fursov wrote:
> > Could it be better if we mark bugs that worth to be fixed before JavaOne as
> > Critical to simplify stats tracking?
>
> We can do that if people think it will be helpful, i.e. create a JIRA
> target and mark those issues that we think MUST be fixed by then.
>
> I'll be doing some extra testing too, so will flag problems found in app
> tests.
>
> Regards,
> Tim
>
>
Re: [general] Reminder: stable build goal at end of month
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Fursov wrote:
> Could it be better if we mark bugs that worth to be fixed before JavaOne as
> Critical to simplify stats tracking?
We can do that if people think it will be helpful, i.e. create a JIRA
target and mark those issues that we think MUST be fixed by then.
I'll be doing some extra testing too, so will flag problems found in app
tests.
Regards,
Tim
Re: [general] Reminder: stable build goal at end of month
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/16/07, Tim Ellison <t....@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.
Could it be better if we mark bugs that worth to be fixed before JavaOne as
Critical to simplify stats tracking?
--
Mikhail Fursov
Re: [general] Reminder: stable build goal at end of month
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 4/18/07, Xiao-Feng Li <xi...@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 <iv...@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 <al...@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 <rd...@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 <mi...@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 <xi...@gmail.com> wrote:
> > > > > >
> > > > > > On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
>
Re: [general] Reminder: stable build goal at end of month
Posted by Leo Li <li...@gmail.com>.
Waiting to see...
A new GC, with enhanced performance and stable behavior.:)
On 4/19/07, Alexey Petrenko <al...@gmail.com> wrote:
>
> No objections from me.
> When we plan to switch to GCv5?
>
> SY, Alexey
>
> 2007/4/19, Stepan Mishura <st...@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....@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 <iv...@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 <al...@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 <rd...@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 <mi...@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 <xi...@gmail.com> wrote:
> > > > >> > > > >
> > > > >> > > > > On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
> >
>
--
Leo Li
China Software Development Lab, IBM
Re: [general] Reminder: stable build goal at end of month
Posted by Alexey Petrenko <al...@gmail.com>.
No objections from me.
When we plan to switch to GCv5?
SY, Alexey
2007/4/19, Stepan Mishura <st...@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....@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 <iv...@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 <al...@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 <rd...@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 <mi...@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 <xi...@gmail.com> wrote:
> > > >> > > > >
> > > >> > > > > On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
>
Re: [general] Reminder: stable build goal at end of month
Posted by Stepan Mishura <st...@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....@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 <iv...@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 <al...@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 <rd...@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 <mi...@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 <xi...@gmail.com> wrote:
> > >> > > > >
> > >> > > > > On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
Re: [general] Reminder: stable build goal at end of month
Posted by Tim Ellison <t....@gmail.com>.
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
Agreed.
Tim
Re: [general] Reminder: stable build goal at end of month
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/18/07, Mikhail Loenko <ml...@gmail.com> 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
Right, this is also what I think. :-)
Thanks,
xiaofeng
> Thanks,
> Mikhail
>
> 2007/4/18, Tim Ellison <t....@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 <iv...@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 <al...@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 <rd...@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 <mi...@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 <xi...@gmail.com> wrote:
> > >> > > > >
> > >> > > > > On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
Re: [general] Reminder: stable build goal at end of month
Posted by Mikhail Loenko <ml...@gmail.com>.
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....@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 <iv...@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 <al...@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 <rd...@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 <mi...@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 <xi...@gmail.com> wrote:
> >> > > > >
> >> > > > > On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: [general] Reminder: stable build goal at end of month
Posted by Tim Ellison <t....@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 <iv...@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 <al...@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 <rd...@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 <mi...@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 <xi...@gmail.com> wrote:
>> > > > >
>> > > > > On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
>> > > >
>> > >
>> >
>>
>
>
Re: [general] Reminder: stable build goal at end of month
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <iv...@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 <al...@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 <rd...@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 <mi...@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 <xi...@gmail.com> wrote:
> > > > >
> > > > > On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
Re: [general] Reminder: stable build goal at end of month
Posted by Vladimir Ivanov <iv...@gmail.com>.
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 <al...@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 <rd...@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 <mi...@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 <xi...@gmail.com> wrote:
> > > >
> > > > On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
> > >
> >
>
Re: [general] Reminder: stable build goal at end of month
Posted by Alexey Petrenko <al...@gmail.com>.
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 <rd...@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 <mi...@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 <xi...@gmail.com> wrote:
> > >
> > > On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
> >
>
Re: [general] Reminder: stable build goal at end of month
Posted by Mikhail Fursov <mi...@gmail.com>.
I'm Ok.
It's not an urgent problem until we have only one GC (gcv4 in the past and
gcv5 in the future) and do not need to modify emconf files often.
On 4/18/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> On 4/18/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > On 4/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > >
> > > In addition to specs and eclipse, there are the tests that come with
> > > "build test". Are there any more tests we are worried about?
> >
> >
> > It can be unrelated to JavaOne milestone but we must start thinking that
> we
> > are worried about any application written on Java if we want to
> > annouce 1.5release soon.
> > I try different 3rd party application daily with Harmony (and gcv4) and
> have
> > rather odd results: we run almost everything, but every app I tried
> > reveals at least one bug/incompatibility that prevents it run on
> Harmony.
> > Most of the problems I have are with classlib/VM/JIT but not GC ones. I
> hope
> > gcv5 have the same stability level as gcv4.
> >
> > 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?
> >
> >
> > If we have 2-3 weeks I'm +1 to try.
> > + We have to update server.emconf in this case.
> >
> > BTW I remember a proposal to move all GC helpers written in Java with
> magic
> > into the same package (i.e. avoid .gc_cc. or .gc_gen. token in the
> package
> > name). In this case we can switch GC without additional changes in
> > server.emconf. Xiao-Feng, what do you think about it?
>
> Mikhail, I think it's a good idea to let server conf run with
> different GCs without modifications. The real problem is, we need a
> way to inform EM which helpers are inlined for different GCs. Maybe
> this GC-specific conf can stay with the GC?
>
> Thanks,
> xiaofeng
>
> >
> > --
> > Mikhail Fursov
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
--
Mikhail Fursov
Re: [general] Reminder: stable build goal at end of month
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/18/07, Mikhail Fursov <mi...@gmail.com> wrote:
> On 4/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
> >
> > In addition to specs and eclipse, there are the tests that come with
> > "build test". Are there any more tests we are worried about?
>
>
> It can be unrelated to JavaOne milestone but we must start thinking that we
> are worried about any application written on Java if we want to
> annouce 1.5release soon.
> I try different 3rd party application daily with Harmony (and gcv4) and have
> rather odd results: we run almost everything, but every app I tried
> reveals at least one bug/incompatibility that prevents it run on Harmony.
> Most of the problems I have are with classlib/VM/JIT but not GC ones. I hope
> gcv5 have the same stability level as gcv4.
>
> 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?
>
>
> If we have 2-3 weeks I'm +1 to try.
> + We have to update server.emconf in this case.
>
> BTW I remember a proposal to move all GC helpers written in Java with magic
> into the same package (i.e. avoid .gc_cc. or .gc_gen. token in the package
> name). In this case we can switch GC without additional changes in
> server.emconf. Xiao-Feng, what do you think about it?
Mikhail, I think it's a good idea to let server conf run with
different GCs without modifications. The real problem is, we need a
way to inform EM which helpers are inlined for different GCs. Maybe
this GC-specific conf can stay with the GC?
Thanks,
xiaofeng
>
> --
> Mikhail Fursov
>
--
http://xiao-feng.blogspot.com
Re: [general] Reminder: stable build goal at end of month
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
>
> In addition to specs and eclipse, there are the tests that come with
> "build test". Are there any more tests we are worried about?
It can be unrelated to JavaOne milestone but we must start thinking that we
are worried about any application written on Java if we want to
annouce 1.5release soon.
I try different 3rd party application daily with Harmony (and gcv4) and have
rather odd results: we run almost everything, but every app I tried
reveals at least one bug/incompatibility that prevents it run on Harmony.
Most of the problems I have are with classlib/VM/JIT but not GC ones. I hope
gcv5 have the same stability level as gcv4.
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?
If we have 2-3 weeks I'm +1 to try.
+ We have to update server.emconf in this case.
BTW I remember a proposal to move all GC helpers written in Java with magic
into the same package (i.e. avoid .gc_cc. or .gc_gen. token in the package
name). In this case we can switch GC without additional changes in
server.emconf. Xiao-Feng, what do you think about it?
--
Mikhail Fursov
Re: [general] Reminder: stable build goal at end of month
Posted by Rana Dasgupta <rd...@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 <mi...@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 <xi...@gmail.com> wrote:
> >
> > On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
>
Re: [general] Reminder: stable build goal at end of month
Posted by Mikhail Fursov <mi...@gmail.com>.
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 <xi...@gmail.com> wrote:
>
> On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
Re: [general] Reminder: stable build goal at end of month
Posted by Alexey Varlamov <al...@gmail.com>.
Well, putting it reversed, GCv5 is always there to switch to if
desired, the question is whether it is default GC. I consider
switching in the last week as too risky...
Things might be different if we had a couple of weeks to test it.
2007/4/18, Xiao-Feng Li <xi...@gmail.com>:
> On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
>
Re: [general] Reminder: stable build goal at end of month
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/18/07, Mikhail Loenko <ml...@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 <xi...@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....@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
Re: [general] Reminder: stable build goal at end of month
Posted by Mikhail Loenko <ml...@gmail.com>.
Do you think we should switch before "end of month"?
It's certainly a risk, but what is the value in the switch?
Thanks,
Mikhail
2007/4/18, Xiao-Feng Li <xi...@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....@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
>
Re: [general] Reminder: stable build goal at end of month
Posted by Alexey Petrenko <al...@gmail.com>.
+1
2007/4/21, Mikhail Fursov <mi...@gmail.com>:
> On 4/21/07, Alexey Varlamov <al...@gmail.com> wrote:
> >
> > Let's switch now - so that more automated tests could be run during
> > this weekend.
>
>
> +1
>
>
>
> --
> Mikhail Fursov
>
Re: [general] Reminder: stable build goal at end of month
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/21/07, Alexey Varlamov <al...@gmail.com> wrote:
>
> Let's switch now - so that more automated tests could be run during
> this weekend.
+1
--
Mikhail Fursov
Re: [general] Reminder: stable build goal at end of month
Posted by Xiao-Feng Li <xi...@gmail.com>.
Ok, I will make the switch now.
Thanks,
xiaofeng
On 4/21/07, Tim Ellison <t....@gmail.com> wrote:
> Alexey Varlamov wrote:
> > Let's switch now - so that more automated tests could be run during
> > this weekend.
>
> Agreed -- the sooner the better.
>
> Tim
>
--
http://xiao-feng.blogspot.com
Re: [general] Reminder: stable build goal at end of month
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov wrote:
> Let's switch now - so that more automated tests could be run during
> this weekend.
Agreed -- the sooner the better.
Tim
Re: [general] Reminder: stable build goal at end of month
Posted by Alexey Varlamov <al...@gmail.com>.
Let's switch now - so that more automated tests could be run during
this weekend.
2007/4/21, Xiao-Feng Li <xi...@gmail.com>:
> Do we want to switch tomorrow or on Monday for a one-week trial? The
> test results last night showed GCv5 has reasonable stability now. Many
> thanks to Vladimir A Ivanov for the testing infrastructure.
>
> From the testing logs at http://www.harmonytest.org/upload/cc2.html,
> we can see there are only a couple of test case failures in all the
> platforms with all the execution modes. Some of the failures are
> occasional actually, especially those with finalizer.
>
> Below is a summary of the testing status:
> Linux 32bit: all passed.
> Linux 64bit: only one case failure: gc.RunFinalizersOnExitTest (interpreter)
> Windows 32bit: only one case failure: exception.FinalizeStackTest (opt/srv)
> Windows 64bit: more test failures. Some are abnormal that we didn't met before.
>
> All the failure cases will be checked.
>
> (Note GCv4.1 sometimes fails with some test cases as well.)
>
> Thanks,
> xiaofeng
>
> On 4/18/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > 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....@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
>
Re: [general] Reminder: stable build goal at end of month
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/23/07, Tim Ellison <t....@gmail.com> wrote:
> Xiao-Feng Li wrote:
> > On 4/22/07, Tim Ellison <t....@gmail.com> wrote:
> >> Is there any documentation for GCv5 on the website? I didn't see any
> >> but admit I didn't look extensively.
> >
> > Not yet. Last year when I developed it, I reported the design and
> > progress every one or two weeks in the mailing list. Surely I will
> > write down the implementation (algorithm and code) when I get some
> > free time. Just too busy to get the code ready. Probably I can put
> > some overview info into a powerpoint.
>
> Highlights (maybe on the wiki?) would be good, just so we can point to
> some of the cool features in GCv5.
I've put a wiki page for DRLVM GC at
http://wiki.apache.org/harmony/MemoryManager (its entry is at
HarmonyArchitecture page). The page will be kept updated.
Thanks,
xiaofeng
> Thanks
> Tim
>
--
http://xiao-feng.blogspot.com
Re: [general] Reminder: stable build goal at end of month
Posted by Tim Ellison <t....@gmail.com>.
Xiao-Feng Li wrote:
> On 4/22/07, Tim Ellison <t....@gmail.com> wrote:
>> Is there any documentation for GCv5 on the website? I didn't see any
>> but admit I didn't look extensively.
>
> Not yet. Last year when I developed it, I reported the design and
> progress every one or two weeks in the mailing list. Surely I will
> write down the implementation (algorithm and code) when I get some
> free time. Just too busy to get the code ready. Probably I can put
> some overview info into a powerpoint.
Highlights (maybe on the wiki?) would be good, just so we can point to
some of the cool features in GCv5.
Thanks
Tim
Re: [general] Reminder: stable build goal at end of month
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/22/07, Tim Ellison <t....@gmail.com> wrote:
> Xiao-Feng Li wrote:
> > Folks, I did the switch minutes ago. Let's see how it goes. We'd
> > expect some regressions, especially for those tests not run with GCv5
> > before. Helps to resolve the regressions would be greatly appreciated,
> > so as to bring Harmony an advanced stop-the-world GC.
>
> Great (you might want to call this out in a new thread in case people
> are ignoring this one, and miss your news).
Ok, will do.
> Is there any documentation for GCv5 on the website? I didn't see any
> but admit I didn't look extensively.
Not yet. Last year when I developed it, I reported the design and
progress every one or two weeks in the mailing list. Surely I will
write down the implementation (algorithm and code) when I get some
free time. Just too busy to get the code ready. Probably I can put
some overview info into a powerpoint.
Thanks,
xiaofeng
> > I had a quick examination over the failures. I found some of the
> > finalizer failures are actually related to VM shutdown issue. And I
> > found the reg.test timeout failures in Win64 can't be reproduced if I
> > ran them individually with java.exe command line. The timeout happens
> > when I ran them in build.bat. I tried with gcv4.1, it has the same
> > issue. So I assume I can ignore those failures at the moment. I will
> > continue to check the remaining finalizer failures.
>
> ack -- thanks.
>
> Regards,
> Tim
>
--
http://xiao-feng.blogspot.com
Re: [general] Reminder: stable build goal at end of month
Posted by Tim Ellison <t....@gmail.com>.
Xiao-Feng Li wrote:
> Folks, I did the switch minutes ago. Let's see how it goes. We'd
> expect some regressions, especially for those tests not run with GCv5
> before. Helps to resolve the regressions would be greatly appreciated,
> so as to bring Harmony an advanced stop-the-world GC.
Great (you might want to call this out in a new thread in case people
are ignoring this one, and miss your news).
Is there any documentation for GCv5 on the website? I didn't see any
but admit I didn't look extensively.
> I had a quick examination over the failures. I found some of the
> finalizer failures are actually related to VM shutdown issue. And I
> found the reg.test timeout failures in Win64 can't be reproduced if I
> ran them individually with java.exe command line. The timeout happens
> when I ran them in build.bat. I tried with gcv4.1, it has the same
> issue. So I assume I can ignore those failures at the moment. I will
> continue to check the remaining finalizer failures.
ack -- thanks.
Regards,
Tim
Re: [general] Reminder: stable build goal at end of month
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/21/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Xiao-Feng Li <xi...@gmail.com>
> Date: Apr 21, 2007 12:08 PM
> Subject: Re: [general] Reminder: stable build goal at end of month
> To: dev@harmony.apache.org
>
>
> Do we want to switch tomorrow or on Monday for a one-week trial? The
> test results last night showed GCv5 has reasonable stability now. Many
> thanks to Vladimir A Ivanov for the testing infrastructure.
>
> From the testing logs at http://www.harmonytest.org/upload/cc2.html,
> we can see there are only a couple of test case failures in all the
> platforms with all the execution modes. Some of the failures are
> occasional actually, especially those with finalizer.
>
> Below is a summary of the testing status:
> Linux 32bit: all passed.
> Linux 64bit: only one case failure: gc.RunFinalizersOnExitTest (interpreter)
> Windows 32bit: only one case failure: exception.FinalizeStackTest (opt/srv)
> Windows 64bit: more test failures. Some are abnormal that we didn't met before.
Folks, I did the switch minutes ago. Let's see how it goes. We'd
expect some regressions, especially for those tests not run with GCv5
before. Helps to resolve the regressions would be greatly appreciated,
so as to bring Harmony an advanced stop-the-world GC.
I had a quick examination over the failures. I found some of the
finalizer failures are actually related to VM shutdown issue. And I
found the reg.test timeout failures in Win64 can't be reproduced if I
ran them individually with java.exe command line. The timeout happens
when I ran them in build.bat. I tried with gcv4.1, it has the same
issue. So I assume I can ignore those failures at the moment. I will
continue to check the remaining finalizer failures.
Thanks,
xiaofeng
> All the failure cases will be checked.
>
> (Note GCv4.1 sometimes fails with some test cases as well.)
>
> Thanks,
> xiaofeng
>
> On 4/18/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > 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....@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
>
>
> --
> http://xiao-feng.blogspot.com
>
--
http://xiao-feng.blogspot.com
--
http://xiao-feng.blogspot.com
Re: [general] Reminder: stable build goal at end of month
Posted by Xiao-Feng Li <xi...@gmail.com>.
Do we want to switch tomorrow or on Monday for a one-week trial? The
test results last night showed GCv5 has reasonable stability now. Many
thanks to Vladimir A Ivanov for the testing infrastructure.
>From the testing logs at http://www.harmonytest.org/upload/cc2.html,
we can see there are only a couple of test case failures in all the
platforms with all the execution modes. Some of the failures are
occasional actually, especially those with finalizer.
Below is a summary of the testing status:
Linux 32bit: all passed.
Linux 64bit: only one case failure: gc.RunFinalizersOnExitTest (interpreter)
Windows 32bit: only one case failure: exception.FinalizeStackTest (opt/srv)
Windows 64bit: more test failures. Some are abnormal that we didn't met before.
All the failure cases will be checked.
(Note GCv4.1 sometimes fails with some test cases as well.)
Thanks,
xiaofeng
On 4/18/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> 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....@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
Re: [general] Reminder: stable build goal at end of month
Posted by Xiao-Feng Li <xi...@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....@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