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 Sun, 12 Nov 2006 15:25:33 GMT
On 11/10/06, Alexei Zakharov <alexei.zakharov@gmail.com> wrote:
>
> > Sure, contributors should check debug or even both debug and release
> builds
> > and comment about this in JIRA.
>
> As far as I understand the only person who answers for the commit is a
> committer. So I don't think that establishing a policy that shifts a
> part of responsibility from the committer is a good idea.
>
> Well, I have another silly question to gurus indeed. Is there any
> possibility that some piece of code can break / hang the release build
> if it passes ok on the debug build?



 Theoretically it is possible to have problems on release build even if
debug build passes the checks. More sofisticated optimizations applied in
release build may reveal some subtle error in the code. Practically tis is
not a common case though.

Thanks,
Pavel

Thanks,
>
> 2006/11/10, Pavel Ozhdikhin <pavel.ozhdikhin@gmail.com>:
> > 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
>
>
>
> --
> Alexei Zakharov,
> Intel Enterprise Solutions Software Division
>

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