ee4f89378d
* Speedy Tail call optimization The goal of this PR is to achieve Tail call optimization #5767 Tail call optimization means that tail-calls execute without consuming resources. In particular, they must not consume stack space. Speedy has two stacks: The `env`-stack and the `kontStack`. For an optimized tail call in Speedy, we must not extend either. In Speedy, all function calls are executed via the code `enterFullyAppliedFunction`. The behaviour of this code (prior to this PR) is as follows: (1) Push the values of all args and free-variables on the env-stack (because that's where the code expects to find them), and (2) Push a KPop continuation on the kontStack, which will restore the env-stack to its original size before returning to the code which made the function call. We must stop doing both these things. We achieve this as follows: (1) We address function args and free-vars via a new machine component: the current `frame`. (2) We make continuations responsible for restoring their own environment. As well as achieving proper tail calls, we also gain a performance improvement by (a) removing the many pushes to the env-stack, and (b) never having to push (and then later re-enter) a KPop continuation. The args array and the free-vars array already existed, so there is no additional cost associated with constructing these array. The only extra costs (which are smaller than the gains) are that we must manage the new `frame` component of the machine, and we must record frame/env-size information in continuations so they can restore their environment. To make use of the frame, we need to identify (at compile time) the run-time location for every variable in a speedy expression. This is done during the `closureConvert` phase. At run-time, an environment is now composed of both the existing env-stack and the frame. The only values which now live on the env-stack are those introduced by let-bindings and pattern-match-destructuring. All other are found in the frame. Changes to SEExpr: - Introduce a new expression form `SELoc`, with 3 sub classes: SELocS/SELocA/SELocF to represent the run-time location of a variable. - SELocS/A/F execute by calling corresponding lookup function in Speedy: getEnv(Stack,Arg,Free). - SEMakeClo takes a list of SELoc instead of list of int. - During closure conversion all SEVar are replaced by an SELocS/A/F. - SEVar are not allowed to exist at run-time (just as SEAbs may not exist). - We adapt the synthesised code for SEBuiltinRecursiveDefinition: FoldL, FoldR, EqualList It is worth noting the prior code also had the notion of before/after closureConvert, but SEVar was used for both meanings: Prior to closureConvert it meant the relative-index of the enclosing binder (lambda,let,..). After closureConvert it meant the relative-offset from the top of the env-stack where the value would be found at run-time. These are not quite the same! Now we have different sub-types (SEVar vs SELoc), this change of mode is made more explicit. Run-time changes: - Use the existing `KFun` continuation as the new `Frame` component. - `KFun` allows access to both the args of the current application, and the free-vars of the current closure. - A variable is looked up by it's run-time location (SELocS/A/F) - A function application is executed (`enterFullyAppliedFunction`), by setting the machine's `frame` component to the new current `KFun`. - When a continuation (KArg, KMatch, KPushTo, KCatch) is pushed, we record the current Frame and current stack depth within the continuation, so when it is entered, it can call `restoreEnv` to restore the environment to the state when the continuation was pushed. Changes to Compiler: - The required changes are to the `closureConvert` and `validate`. - `closureConvert` `remaps` is now a `Map` from the `SEVar`s relative-index to `SELoc` - `validate` now tracks 3-ints (maxS,masA,maxF) changelog_begin changelog_end * changes for Remy * Changes for Martin * test designed explicitly to blow if the free variables are captured incorrectly * address more comments * improve comment about shift in Compiler |
||
---|---|---|
.github | ||
.vscode | ||
3rdparty | ||
bazel_tools | ||
build-scripts | ||
ci | ||
compatibility | ||
compiler | ||
daml-assistant | ||
daml-lf | ||
daml-script | ||
dev-env | ||
docs | ||
extractor | ||
ghc-lib | ||
infra | ||
language-support | ||
ledger | ||
ledger-api | ||
ledger-service | ||
libs-haskell | ||
libs-scala | ||
navigator | ||
nix | ||
oss-compliance | ||
release | ||
replacements | ||
rules_daml | ||
scala-protoc-plugins | ||
templates | ||
triggers | ||
.bazelignore | ||
.bazelrc | ||
.dadew | ||
.dockerignore | ||
.envrc | ||
.gitattributes | ||
.gitignore | ||
.hie-bios | ||
.hlint.yaml | ||
.mergify.yml | ||
.scalafmt.conf | ||
.sha256 | ||
.watchmanconfig | ||
azure-cron.yml | ||
azure-pipelines.yml | ||
BAZEL-bash.md | ||
bazel-haskell-deps.bzl | ||
BAZEL-haskell.md | ||
bazel-java-deps.bzl | ||
BAZEL-JVM.md | ||
BAZEL.md | ||
BUILD | ||
build.ps1 | ||
build.sh | ||
CHANGELOG | ||
CODE_OF_CONDUCT.md | ||
CODEOWNERS | ||
CONTRIBUTING.md | ||
COPY | ||
daml-logo.png | ||
deps.bzl | ||
dotfiles | ||
fmt.sh | ||
LATEST | ||
LICENSE | ||
maven_install.json | ||
NOTICES | ||
package.json | ||
README.md | ||
release.sh | ||
report-std-change.sh | ||
SECURITY.md | ||
stack-snapshot.yaml | ||
tsconfig.json | ||
unreleased.rst | ||
unreleased.sh | ||
Upgrading.md | ||
WORKSPACE | ||
workspace_status.sh | ||
yarn.lock |
Copyright 2020 Digital Asset (Switzerland) GmbH and/or its affiliates. All Rights Reserved. SPDX-License-Identifier: Apache-2.0
Welcome to the DAML repository!
This repository hosts all code for the DAML smart contract language and SDK, originally created by Digital Asset. DAML is an open-source smart contract language for building future-proof distributed applications on a safe, privacy-aware runtime. The DAML SDK is a set of tools to help you develop applications based on DAML.
Using DAML
To download DAML, follow the installation instructions. Once installed, to try it out, follow the quickstart guide.
If you have questions about how to use DAML or how to build DAML-based solutions, please ask them
on StackOverflow using the daml
tag.
Contributing to DAML
We warmly welcome contributions. If you are looking for ideas on how to contribute, please browse our issues. To build and test DAML:
1. Clone this repository
git clone git@github.com:digital-asset/daml.git
cd daml
2. Set up the development dependencies
Our builds require various development dependencies (e.g. Java, Bazel, Python), provided by a tool called dev-env
.
Linux and Mac
On Linux and Mac dev-env
can be installed with:
- Install Nix by running:
bash <(curl https://nixos.org/nix/install)
- Enter
dev-env
by running:eval "$(dev-env/bin/dade assist)"
If you don't want to enter dev-env
manually each time using eval "$(dev-env/bin/dade assist)"
,
you can also install direnv. This repo already provides a .envrc
file, with an option to add more in a .envrc.private
file.
Windows
On Windows you need to enable long file paths by running the following command in an admin powershell:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Type DWord -Value 1
Then start dev-env
from PowerShell with:
.\dev-env\windows\bin\dadew.ps1 install
.\dev-env\windows\bin\dadew.ps1 sync
.\dev-env\windows\bin\dadew.ps1 enable
In all new PowerShell processes started, you need to repeat the enable
step.
3. First build and test
We have a single script to build most targets and run the tests. On Linux and Mac run ./build.sh
. On Windows run .\build.ps1
. Note that these scripts may take over an hour the first time.
To just build do bazel build //...
, and to just test do bazel test //...
. To read more about Bazel and how to use it, see the Bazel site.
On Mac if building is causing trouble complaining about missing nix packages, you can try first running nix-build -A tools -A cached nix
repeatedly until it completes without error.
4. Installing a local copy
On Linux and Mac run daml-sdk-head
which installs a version of the SDK with version number 0.0.0
. Set the version:
field in any DAML project to 0.0.0 and it will use the locally installed one.
On Windows:
bazel build //release:sdk-release-tarball
tar -vxf .\bazel-bin\release\sdk-release-tarball.tar.gz
cd sdk-*
daml\daml.exe install . --activate
That should tell you what to put in the path, something along the lines of C:\Users\admin\AppData\Roaming\daml\bin
.
Note that the Windows build is not yet fully functional.
Caching: build speed and disk space considerations
Bazel has a lot of nice properties, but they come at the cost of frequently rebuilding "the world".
To make that bearable, we make extensive use of caching. Most artifacts should be cached in our CDN,
which is configured in .bazelrc
in this project.
However, even then, you may end up spending a lot of time (and bandwidth!) downloading artifacts from
the CDN. To alleviate that, by default, our build will create a subfolder .bazel-cache
in this
project and keep an on-disk cache. This can take about 10GB at the time of writing.
To disable the disk cache, remove the following lines:
build:linux --disk_cache=.bazel-cache
build:darwin --disk_cache=.bazel-cache
from the .bazelrc
file.
If you work with multiple copies of this repository, you can point all of them to the same disk cache
by overwriting these configs in either a .bazelrc.local
file in each copy, or a ~/.bazelrc
file
in your home directory.
Haskell profiling builds
To build Haskell executables with profiling enabled, pass -c dbg
to
Bazel, e.g. bazel build -c dbg damlc
. If you want to build the whole
SDK with profiling enabled use daml-sdk-head --profiling
.