So, the time spent for pre-commit checks won't be a big problem in this case. Enabling JIT to be built in debug by default (what I think we should do) will add just 20-30% to this time.
Thanks, Pavel On 11/10/06, Gregory Shimansky <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. <[EMAIL PROTECTED]> 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 -- Gregory
