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 06:07:44 GMT
+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