Status report, JIT middle-end looks good but stress testing compels revisiting scheduler and memory management
April 28, 2011
Posted by on
JIT middle-end stuff looks good. Some transformations are in bytecode (constants, invariants, loop rolling) while others are in object trees (reductions, kernel boundaries, reordering, variables). Everything fits into the design as-is. Compilers are cool.
I was hoping to get far enough to start work on the OpenCL back-end. As harder stuff is done in the middle-end (where it should be), the back-end should be thin and relatively easy. Note the earlier JIT code was a total hack and completely unsuitable.
Unfortunately, I need to revisit scheduling and memory management. Realistic parallel/concurrent test code (dozens or hundreds of threads) that stresses the runtime is intermittently segfaulting and crashing. My goal is a useful platform for real-world use. So I can’t look the other way and pretend it’s not happening.
My experience using Java and Oracle is that managed platforms often have trouble under high loads, even with performance tuning. That’s ok most of the time. Systems move to “share nothing” and scale horizontally.
I think it’s different for GPUs and HPC. Applications are expected to maximize load and stress the system. If a managed platform can’t handle this, why use it? It’s too much trouble.