regrtest.py cannot be run under -j always

[GoogleCodeExporter]

We've been trying to get regrtest.py to run successfully under -j always
for awhile now.  Here are the problems we've run into, and their fixes:

1. LLVM had a hard-coded limit on the size of generated machine code.  I
committed a fix for this to LLVM.
2. During instruction scheduling, we overflowed a short in one of LLVM's
data structures.  I committed a patch to LLVM to avoid the overflow and
allow longer basic blocks.
3. Currently, running regrtest.py under -j always segfaults during
test_import.  I haven't traced the execution in GDB, because GDB traps a
number of times during the test suite and has to be continued manually.

Before the segfault, a number of tests fail with exceptions from os.fork
returning an error code claiming that the kernel can't allocate memory. 
This happens for me on my desktop system which has 6 GB of RAM (that should
be plenty).  My first theory for what's happening is that malloc is finally
returning NULL because it's run out of memory, and that's causing the segfault.

Can someone else confirm this overnight?  Save your state before you do,
because the Linux out-of-memory killer might come and reap your firefox
process.

Original issue reported on code.google.com by reid.kle...@gmail.com on 1 Oct 2009 at 3:27

[GoogleCodeExporter]

The situation has improved somewhat, but I think it's mostly because we stopped
compiling as much code.  On my main machine, I have two unexpected test failures
under -j always:
test_code -- I have a fix for these weakref tests out for review.
test_multiprocessing -- This reliably fails when I run it from regrtest, but it 
does
not when I run it in isolation.
test_mailbox -- This must be flaky or have a race condition, because I've never 
seen
this failure before and it just popped up.

Original comment by reid.kle...@gmail.com on 30 Dec 2009 at 7:00

[GoogleCodeExporter]

One issue I would add to this is that test_subprocess takes *forever* to run 
under -j 
always. This is due to the massive increase in startup time caused by -j 
always. This test 
currently times out on the buildslaves. We may want to disable JIT compilation 
during 
startup and only turn it on after the interpreter has started.

Reid, thoughts on that?

Original comment by collinw on 11 Jan 2010 at 7:58

[GoogleCodeExporter]

If it's OK with you, it's OK with me.

Personally, what I'd really like to see replace -j always, is a testing setting 
where
we drastically lower the hotness threshold.  This setting would aggressively 
compile
almost every piece of code that ever gets run, but would allow us to gather at 
least
some feedback, even if it is inaccurate.  This would also achieve the goal of
speeding up startup, because a lot of code is run only once, like module bodies 
and
the code called from them.

I'm imagining either a new hotness threshold flag (-ht?) or a new JITing mode 
that is
equivalent to "whenhot" with a low threshold.  Does this sound like a good idea?

Months ago I tried to implement something similar to this with a "secondcall"
compilation mode, to vigorously exercise the background compilation patch.

Original comment by reid.kle...@gmail.com on 12 Jan 2010 at 1:00

[GoogleCodeExporter]

After r1010, the regression tests pass for me under -j always.  They still take 
a
long time and a lot of memory, so I assume that they still time out on the 
Google
buildbots.  I'll leave this open until that is fixed, probably by avoiding code
compilation during startup.

Original comment by reid.kle...@gmail.com on 20 Jan 2010 at 5:55

[GoogleCodeExporter]

Last I checked, the tests passed under -j always on my machine, and I assume 
that
since r1045 they've passed on the Google build bot.  I'm closing this for now, 
we can
reopen it if they still don't pass for anyone.

Original comment by reid.kle...@gmail.com on 22 Feb 2010 at 5:50

• Changed state: Fixed