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.merc...@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.gr...@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 >> > >
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
