Introspection bug in BaseX7.8 beta 4cfa54c ?

On Thu, Jan 30, 2014 at 5:07 PM, jean-marc Mercier <jeanmarc.mercier at gmail.com> wrote: > Hello, > > As bug https://github.com/BaseXdb/basex/issues/839 has been closed, I tried > to upgrade from BaseX7.8 6aeaebf to BaseX beta_4cfa54c. > Unfortunately, this bug still appears in 4cfa54c, and I rolled back again to > beta 6aeaebf . > Did I misunderstoog something ? > > Cheers > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >

> Hi Jean-Marc, > > you got it right, we fixed the bug! I've just updated the snapshot; > feel free to give it a try! > > Thanks, > Christian > > > > On Thu, Jan 30, 2014 at 5:07 PM, jean-marc Mercier > <jeanmarc.mercier at gmail.com> wrote: > > Hello, > > > > As bug https://github.com/BaseXdb/basex/issues/839 has been closed, I > tried > > to upgrade from BaseX7.8 6aeaebf to BaseX beta_4cfa54c. > > Unfortunately, this bug still appears in 4cfa54c, and I rolled back > again to > > beta 6aeaebf . > > Did I misunderstoog something ? > > > > Cheers > > > > _______________________________________________ > > BaseX-Talk mailing list > > BaseX-Talk at mailman.uni-konstanz.de > > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > >

> Hi Christian, > > Thx, I tested it. It seems that a regression has been introduced : my main > process, running in 30sec with 4 Go in memory with BaseX7.8 6aeaebf, > never ended with this latest release. Indeed, it started disk-swapping as > it is consuming more than 6 Go now (the size heap of my JAVA machine). > > Do you have any clue, or suggestion, that could help us finding this > regression ? > > Cheers, > > Jean-Marc > > > > > 2014-01-30 Christian Grün <christian.gruen at gmail.com> > > Hi Jean-Marc, >> >> you got it right, we fixed the bug! I've just updated the snapshot; >> feel free to give it a try! >> >> Thanks, >> Christian >> >> >> >> On Thu, Jan 30, 2014 at 5:07 PM, jean-marc Mercier >> <jeanmarc.mercier at gmail.com> wrote: >> > Hello, >> > >> > As bug https://github.com/BaseXdb/basex/issues/839 has been closed, I >> tried >> > to upgrade from BaseX7.8 6aeaebf to BaseX beta_4cfa54c. >> > Unfortunately, this bug still appears in 4cfa54c, and I rolled back >> again to >> > beta 6aeaebf . >> > Did I misunderstoog something ? >> > >> > Cheers >> > >> > _______________________________________________ >> > BaseX-Talk mailing list >> > BaseX-Talk at mailman.uni-konstanz.de >> > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> > >> > >

> A first clue: I set INLINELIMIT = 0 TAILCALL = -1, and the process ended, > even if it is taking now some 3/4 minutes and nearly 5,5 Go memory > footprint.

> > A first clue: I set INLINELIMIT = 0 TAILCALL = -1, and the process ended, > > even if it is taking now some 3/4 minutes and nearly 5,5 Go memory > > footprint. > > Thanks. Could you provide us with a self-contained query? > Christian >

On Thu, Jan 30, 2014 at 9:39 PM, jean-marc Mercier < jeanmarc.mercier at gmail.com> wrote: > Christian, > > The point is that I don't know how to provide a self-contained query. > > The only strategy I could propose, to provide a self-contained query > isolating the memory management problem, is really too time-consuming : I > can imagine a binary-chop search, comparing the memory management of the > two BaseX beta versions, over a very complex algorithm, to isolate the > problem. This is probably a week work, I can't spend such a time. > > Do you have a better strategy to find the problem ? > > > > > 2014-01-30 Christian Grün <christian.gruen at gmail.com> > > > A first clue: I set INLINELIMIT = 0 TAILCALL = -1, and the process ended, >> > even if it is taking now some 3/4 minutes and nearly 5,5 Go memory >> > footprint. >> >> Thanks. Could you provide us with a self-contained query? >> Christian >> > >

> If you got time, it may already be helpful if you provide us with your > code base. You could also try to run BaseX with less memory assigned (e.g. > 128m) and send us the stack trace, which will be triggered via the debug > flag (-d) as soon as RAM is exhausted, or you could run BaseX with Java > profiling arguments (e.g. -Xrunhprof:cpu=sample,depth=15) and provide us > with the output. I can't promise anything, though. > > > On Thu, Jan 30, 2014 at 9:39 PM, jean-marc Mercier < > jeanmarc.mercier at gmail.com> wrote: > >> Christian, >> >> The point is that I don't know how to provide a self-contained query. >> >> The only strategy I could propose, to provide a self-contained query >> isolating the memory management problem, is really too time-consuming : I >> can imagine a binary-chop search, comparing the memory management of the >> two BaseX beta versions, over a very complex algorithm, to isolate the >> problem. This is probably a week work, I can't spend such a time. >> >> Do you have a better strategy to find the problem ? >> >> >> >> >> 2014-01-30 Christian Grün <christian.gruen at gmail.com> >> >> > A first clue: I set INLINELIMIT = 0 TAILCALL = -1, and the process >>> ended, >>> > even if it is taking now some 3/4 minutes and nearly 5,5 Go memory >>> > footprint. >>> >>> Thanks. Could you provide us with a self-contained query? >>> Christian >>> >> >> >

> Mmhh...ok. I will try to find it that way. I am actually trying to send > you the prof:time(prof:mem)) of the main algorithm, to compare the main > perf algorithm between the two betas. > My first penny guess is that it could come from Leo's work, since INLINE > and TAILCALL impacted the result. Could you be kind enough to point me out > his January check-in ? Having a look to his check-in, if we are lucky, > could help me isolate the problem. > > > 2014-01-31 Christian Grün <christian.gruen at gmail.com> > > If you got time, it may already be helpful if you provide us with your >> code base. You could also try to run BaseX with less memory assigned (e.g. >> 128m) and send us the stack trace, which will be triggered via the debug >> flag (-d) as soon as RAM is exhausted, or you could run BaseX with Java >> profiling arguments (e.g. -Xrunhprof:cpu=sample,depth=15) and provide us >> with the output. I can't promise anything, though. >> >> >> On Thu, Jan 30, 2014 at 9:39 PM, jean-marc Mercier < >> jeanmarc.mercier at gmail.com> wrote: >> >>> Christian, >>> >>> The point is that I don't know how to provide a self-contained query. >>> >>> The only strategy I could propose, to provide a self-contained query >>> isolating the memory management problem, is really too time-consuming : I >>> can imagine a binary-chop search, comparing the memory management of the >>> two BaseX beta versions, over a very complex algorithm, to isolate the >>> problem. This is probably a week work, I can't spend such a time. >>> >>> Do you have a better strategy to find the problem ? >>> >>> >>> >>> >>> 2014-01-30 Christian Grün <christian.gruen at gmail.com> >>> >>> > A first clue: I set INLINELIMIT = 0 TAILCALL = -1, and the process >>>> ended, >>>> > even if it is taking now some 3/4 minutes and nearly 5,5 Go memory >>>> > footprint. >>>> >>>> Thanks. Could you provide us with a self-contained query? >>>> Christian >>>> >>> >>> >> >