harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm] release vs. debug
Date Mon, 13 Nov 2006 05:08:24 GMT
When the spec doesn't specify expression evaluation order debug and
release can behave differently. I got into such situation once... :-(

On 11/13/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> Any assert(expr) can change a control flow of the debug build....
>
> On 11/12/06, Pavel Ozhdikhin <pavel.ozhdikhin@gmail.com> wrote:
> > 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
View raw message