General

Assumption is that dynamic compilation is 'better' for any form of parallelisation because

System can adapt to physical resources available and parallelise when appropriate.
System can monitor effects of parallelisation and modify strategy if necessary.

[ jsinger - In the same way that concurrent garbage collection obviates the need to "stop the world" when GC occurs, dynamic compilation on parallel architectures can happen concurrently with execution of user code. This should decrease start-up overhead, increase system throughput ... -jsinger ]

This can (hopefully!) be expanded in the context of particular approaches.

To Support Non-Speculative Parallelisation

Over the years considerable work has been done on extracting parallelism from sequential programs. Most of this work has concentrated on loop constructs, and the usefulness of the parallelism extracted depends to a large degree on achieving low costs for managing the threads and their interactions. Schemes have been invented (e.g. SLAM) in which the compiler-generated code for a loop was capable of being executed in parallel on several processors but may actually only get executed on one, depending on the loading of the system. Although efforts were made to minimise the extra cost incurred by compiling in this way, dynamic compilation allows the compiler to generate parallel code when this is known to be useful, and to generate sequential code when parallel resources are not available. It is also possible to know, for example, the computed bounds of the loop to avoid parallelising loops which would be too small to justify the overheads incurred. What is more an adaptive compiler enables this decision to be remade, so that subsequent executions are not bound by the decisions made just ahead of the first. [CCK]

To Support Speculation

An important issue in the exploitation of speculative parallelism is the choice of 'speculation points' within a serial program. In theory any branch could be a speculation point but only some will be profitable.

[ jsinger - The situation is actually more general than this. A speculation can be characterized by two arbitrary program points, p₀ and p₁, where there is a control flow path from p₀ to p₁. To speculate on ( p₀,p₁) when control reaches p₀, the speculative thread commences execution from p₁, and the non-speculative thread continues execution from p₀. The speculation may be committed when the non-speculative thread reaches p₁. This subsumes loop-level and method-level TLS, not so sure about lock-level TLS ??? -jsinger ]

To Support 'Conventional' TLS

To Support TCC

Better than what?