harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] release vs. debug
Date Fri, 10 Nov 2006 07:16:01 GMT
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