You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 8a61aaa
Browse filesBrowse the repository at this point in the historyBrowse files
Start dependents once a module's interface is final
Why:
On builds limited by a long dependency chain most job slots sit idle
on the critical path: a 136 module library gets only 1.6x from 7
domains.
When a slot would otherwise idle, a module can now start as soon as each
unfinished dependency's interface is final: an implementation without
.resi has computed the .cmi it is about to write, or an interface file
has compiled. The early request reads those .cmi files from memory and
waits at a gate before writing a file, running a command or returning
its result. The scheduler adopts it at the point it would have started
it (dependencies complete, module still dirty), so its code generation
sees the dependencies' .cmj files, and artifacts, diagnostics and
compiler.log are unchanged. Otherwise it is abandoned without effects,
together with anything that started on top of it.
Redirected paths are matched as the build file store keys them. The
directories in which the build publishes interfaces are spelled from
canonical package roots, both in the redirected paths and on the load
path, so a lookup there that matches no redirected path names another
file. A lookup of a redirected file name in any other directory, which
may be an alias from user flags (with -nostdlib those come first), or
one that differs only in case, waits for adoption instead. Whether an
announced interface changes the published one is read from disk, so
that an abandoned request never fills the store. Modules with
js-post-build commands or lowercase .cmi names don't release their
dependents early, and with one domain nothing changes.
Review: Can a dependent see an interface that differs from master's?
It reads the exact contents the dependency then writes, and it is only
adopted after the dependency completed. If the dependency fails later,
for example in code generation, the dependent is abandoned before it
wrote, ran or reported anything.
Signed-off-by: Jono Prest <jjprest@gmail.com>
- Build: start type checking a module as soon as the interfaces of its dependencies are final, instead of waiting for their JavaScript generation, which shortens builds limited by long dependency chains.
0 commit comments