zapashcanon 6 months ago
parent
commit
b3d99f3c99
Signed by: zapashcanon GPG Key ID: 8981C3C62D1D28F1
  1. BIN
      src/ocaml_chain.png
  2. 81
      src/slides.tex

BIN
src/ocaml_chain.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 1.1 MiB

After

Width:  |  Height:  |  Size: 1.1 MiB

81
src/slides.tex

@ -78,6 +78,19 @@
Some primitives such as \mintinline{c}{malloc} need to be rewritten in Wasm and provided by the compiler.
\end{frame}
\begin{frame}[fragile]
How does a GC work ?
\begin{itemize}
\item \emph{Tracing}: we start from \emph{roots} and we find live objects recursively (OCaml, Java)
\item \emph{Reference counting}: we start from dying objects and we kill objects recursively (Python)
\end{itemize}
We need to discriminate pointers:
\begin{itemize}
\item \emph{Conservative (Boehm)}: we make a guess and accept memory leaks (Crystal, Guile, Inkscape).
\item \emph{Precise}: we have the right information (almost everybody).
\end{itemize}
We must have the information somewhere at runtime: quite similar to polymorphism!
\end{frame}
% TODO: how do GC work
% GC languages to Wasm1
@ -98,11 +111,24 @@
\begin{itemize}
\item safe and fast
\item do not make Wasm1 code slower
\item fit with many existing value representation strategies
\item can represent values from any language
\end{itemize}
\end{frame}
% Flambda1
% Compiling Flambda1 to WasmGC
\begin{frame}
A type system to represent values from any kind of source language is too complex.\\
Instead, WasmGC introduces reference types and a subtyping hierarchy:
\begin{center}
\includegraphics[width=20em]{figure_type_hierarchy.mps}
\end{center}
The hierarchy tells which casts are allowed.\\
Upcasts are implicit.\\
Downcasts are explicit and lead to runtime errors if incorrect.\\
Casts are cheap.\\
Possible to dynamically test for compatibility.
\end{frame}
\begin{frame}
\includegraphics[width=25em]{ocaml_chain.png}
@ -143,6 +169,7 @@
\end{frame}
\begin{frame}[fragile]
\fontsize{5pt}{5pt}\selectfont
\begin{minted}{ocaml}
let f =
let s =
@ -193,8 +220,6 @@ iter_print ltwo
\end{minted}
\end{frame}
% Compiling Flambda1 to WasmGC
\begin{frame}
Value representation strategies:
\begin{itemize}
@ -225,19 +250,6 @@ iter_print ltwo
small scalars: \ocaml{bool}, \ocaml{char}, \ocaml{int}, constant constructors of ADTs
\end{frame}
\begin{frame}
A type system to represent values from any kind of source language is too complex.\\
Instead, WasmGC introduces reference types and a subtyping hierarchy:
\begin{center}
\includegraphics[width=20em]{figure_type_hierarchy.mps}
\end{center}
The hierarchy tells which casts are allowed.\\
Upcasts are implicit.\\
Downcasts are explicit and lead to runtime errors if incorrect.\\
Casts are cheap.\\
Possible to dynamically test for compatibility.
\end{frame}
\begin{frame}
\begin{center}
\includegraphics[width=20em]{figure_type_hierarchy.mps}
@ -330,6 +342,19 @@ iter_print ltwo
% TODO: exceptions
\begin{frame}
\begin{description}
\item[monomorphisation] works with Wasm1
\item[boxing everything] works with WasmGC + our strategies
\item[polymorphic boxing] works with WasmGC + our strategies
\item[pointer-tagging] works with WasmGC + our strategies
\item[tagged union] works with WasmGC + our strategies
% TODO: add it back ?
%\item[type-passing] ?
\item[runtime monomorphisation] doesn't work easily
\end{description}
\end{frame}
% Formalized compilation
\begin{frame}
@ -352,7 +377,9 @@ iter_print ltwo
\\
Meant as a way to demonstrate the usefulness of \wasm{i31ref} and convinced the WasmGC working group (along with the Guile implementation that came a few months later).\\
\\
Only a fraction of the stdlib externals are provided and the object fragments of the language has not yet been implemented.
Only a fraction of the stdlib externals are provided and the object fragments of the language has not yet been implemented.\\
\\
The first compiler for a functional language targeting WasmGC.
\end{frame}
@ -364,12 +391,13 @@ iter_print ltwo
\\
No real sized programs for now.\\
\\
Classical functional microbenchmarks are two times slower than native OCaml. Jsoo is slower in an unpredictable fashion.\\
Classical functional microbenchmarks are two times slower than native OCaml..\\
\\
Knuth-Bendix: exceptions are slow (100 times slower than native for a raise) and we need to discuss this with the V8 team (in SpiderMonkey they're fast but other extensions are missing).\\
\\
With casts as no-ops we have a 10\% gain.\\
With optimisations and Flambda2 it should be much better.
With optimisations and Flambda2 it should be much better.\\
Jsoo is slower in an unpredictable fashion (up to 40 times)
% TODO: ^ split in many slides ?
\end{frame}
@ -420,3 +448,16 @@ iter_print ltwo
% Symbolic execution
% TODO: ?
\begin{frame}
Contributions:
\begin{itemize}
\item a Wasm backend for OCaml
\item the first compiler for a functional language to WasmGC
\item impact on the GC proposal for Wasm
\item the first Flambda1 semantics
\item a formalized compilation scheme from Flambda1 to WasmGC
\item compilation strategies usable by others compilers (Guile, Wasm\_of\_ocaml)
\end{itemize}
Thanks !
\end{frame}

Loading…
Cancel
Save