harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] release vs. debug
Date Fri, 10 Nov 2006 14:58:58 GMT
I do the same - I tend to only generally test in debug mode when doing 
series of things, and then doing a release for fun later.

I expect this to be much less of an issue when build-test is up and 
running with debug + release + .....

geir


Gregory Shimansky wrote:
> Well I am always testing patches in _default_ mode which debug for VM, 
> release for JIT and whatever it is for classlib. If defaults change then 
>  it will be some other conditions. Average time to run build test is ~60 
> minutes.
> 
> Pavel Ozhdikhin wrote:
>> 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
View raw message