harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Ozhdikhin" <pavel.ozhdik...@gmail.com>
Subject Re: [drlvm] release vs. debug
Date Fri, 10 Nov 2006 07:49:22 GMT
Sure, contributors should check debug or even both debug and release builds
and comment about this in JIRA.

I'm talking about committers, will they test debug build which takes 5 times
more time? And does it mean they will be able to apply 5 times less patches?


Actually I'm fine if the committers will check both debug and release builds
and I encourage them to check on all supported platforms. But I'm not a
committer. :)

Thanks,
Pavel


On 11/10/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>
> I can understand that the contributor may not have access to multiple
> platforms, but surely he can test using both debug and release builds :-)
> What do we gain by asking the contributor to test less?
>
> Rana
>
>
> On 11/9/06, Pavel Ozhdikhin <pavel.ozhdikhin@gmail.com> wrote:
> >
> > +1 for debug testing before submitting a patch.
> >
> > But, for pre-commit testing we should be careful saying we'll test all
> the
> > patches in debug mode. Though it imprves quality of checks, debug build
> is
> > significantly slower then release, especially when running with
> > interpreter
> > or Jitrino.OPT. I ran "build test" on the DRLVM built in debug mode and
> it
> > takes about 5 times more time than release version on my laptop, The
> times
> > were as follows:
> >
> > "build test", Windows XP/ IA32:
> > DRLVM release: 22 min 55 sec
> > DRLVM debug: 99 min 23 sec
> >
> > So, may be the good choice will be to ask patch submitters to check
> their
> > patches on the debug build and, if the JIRA issue contains comments that
> > this check is passed, committers may test it on release build only.
> >
> > Thanks,
> > Pavel
> >
> > On 11/10/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > >
> > > Well, since the problem is repeatable.... :)
> > >
> > >
> > > Gregory Shimansky wrote:
> > > > Geir Magnusson Jr. wrote:
> > > >>
> > > >>
> > > >> Alexei Zakharov wrote:
> > > >>> Hi DRLVM fans,
> > > >>>
> > > >>> I encountered a rather strange problem while working on some class
> > > >>> library tests. At least two tests from the beans module hang (or
> > > >>> crash) while running on DRLVM debug builds but work fine on DRLVM
> > > >>> release builds. I thought that debug build is something about
> adding
> > > >>> debug symbols to VM binaries and this should not affect the
> > > >>> functionality. Can someone shed a light on this?
> > > >>
> > > >> I would think it's just an assertion firing...
> > > >
> > > > Actually it is more than that. In debug mode TRACE statements are
> > > > compiled and therefore produce executable code. There may also be
> some
> > > > bugs in compiler generating code in different modes (although this
> > > > usually happens for release).
> > > >
> > > > I don't know why hanging happens, but the difference in generated
> code
> > > > is actually quite big. Also assertions or any crashes go to
> > > > exceptions/signal handlers which may happen to loop infinitely,
> there
> > > > were bugs like this happening on the current version of sources,
> look
> > at
> > > > HARMONY-2018 and HADMONY-2006.
> > > >
> > > >>> This is the first
> > > >>> question. The second question - what we should do with such tests.
> > The
> > > >>> tests pass on the downloadable HDK and JRE snapshots as well as
on
> > > >>> classlib + j9. What should be the commit criteria for DRLVM –
i.e.
> > > >>> what is the *true* build? :) I think many people here currently
> use
> > > >>> snapshots to test their patches.
> > > >>
> > > >> debug :)  don't sweep the problems under the rug...
> > > >
> > > > +1
> > > >
> > >
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message