enso-org/enso
1
1
Fork 0
mirror of https://github.com/enso-org/enso.git synced 2024-11-25 21:25:20 +03:00
Code Issues Projects Releases Wiki Activity
c29198eb02
enso/docs/runtime/instruments.md

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

37 lines
1.1 KiB
Markdown
Raw Normal View History

Add task fixing Instruments compilation. (#814) Incremental compilation of instruments may lead to runtime errors when only some of the instruments are recompiled (because the unchanged instruments are not registered by the Annotation Processor). To fix this, we add a task that ensures all instruments are recompiled when at least one of them changes.
2020-06-08 14:56:03 +03:00
---
layout: developer-doc
title: Instruments
category: runtime
tags: [runtime, instruments]
Enable the docker pipeline for releases (#1500)
2021-02-23 17:12:24 +03:00
order: 9
Add task fixing Instruments compilation. (#814) Incremental compilation of instruments may lead to runtime errors when only some of the instruments are recompiled (because the unchanged instruments are not registered by the Annotation Processor). To fix this, we add a task that ensures all instruments are recompiled when at least one of them changes.
2020-06-08 14:56:03 +03:00
---
# Instruments
Add a markdown style guide (#1022)
2020-07-21 15:59:40 +03:00
Add task fixing Instruments compilation. (#814) Incremental compilation of instruments may lead to runtime errors when only some of the instruments are recompiled (because the unchanged instruments are not registered by the Annotation Processor). To fix this, we add a task that ensures all instruments are recompiled when at least one of them changes.
2020-06-08 14:56:03 +03:00
Instruments are used to track runtime events to allow for profiling, debugging
and other kinds of behavior analysis at runtime.
<!-- MarkdownTOC levels="2,3" autolink="true" -->
- [Naming Conventions](#naming-conventions)
- [Fixing Compilation](#fixing-compilation)
<!-- /MarkdownTOC -->
## Naming Conventions
Add a markdown style guide (#1022)
2020-07-21 15:59:40 +03:00
Add task fixing Instruments compilation. (#814) Incremental compilation of instruments may lead to runtime errors when only some of the instruments are recompiled (because the unchanged instruments are not registered by the Annotation Processor). To fix this, we add a task that ensures all instruments are recompiled when at least one of them changes.
2020-06-08 14:56:03 +03:00
Every Instrument must be implemented in Java and have name that ends with
Register instruments/language in their own compilation units to fix the sbt build issues (#3509) New plan to [fix the `sbt` build](https://www.pivotaltracker.com/n/projects/2539304/stories/182209126) and its annoying: ``` log.error( "Truffle Instrumentation is not up to date, " + "which will lead to runtime errors\n" + "Fixes have been applied to ensure consistent Instrumentation state, " + "but compilation has to be triggered again.\n" + "Please re-run the previous command.\n" + "(If this for some reason fails, " + s"please do a clean build of the $projectName project)" ) ``` When it is hard to fix `sbt` incremental compilation, let's restructure our project sources so that each `@TruffleInstrument` and `@TruffleLanguage` registration is in individual compilation unit. Each such unit is either going to be compiled or not going to be compiled as a batch - that will eliminate the `sbt` incremental compilation issues without addressing them in `sbt` itself. fa2cf6a33ec4a5b2e3370e1b22c2b5f712286a75 is the first step - it introduces `IdExecutionService` and moves all the `IdExecutionInstrument` API up to that interface. The rest of the `runtime` project then depends only on `IdExecutionService`. Such refactoring allows us to move the `IdExecutionInstrument` out of `runtime` project into independent compilation unit.
2022-06-13 17:09:08 +03:00
`Instrument`.
Add task fixing Instruments compilation. (#814) Incremental compilation of instruments may lead to runtime errors when only some of the instruments are recompiled (because the unchanged instruments are not registered by the Annotation Processor). To fix this, we add a task that ensures all instruments are recompiled when at least one of them changes.
2020-06-08 14:56:03 +03:00
## Fixing Compilation
Add a markdown style guide (#1022)
2020-07-21 15:59:40 +03:00
Add task fixing Instruments compilation. (#814) Incremental compilation of instruments may lead to runtime errors when only some of the instruments are recompiled (because the unchanged instruments are not registered by the Annotation Processor). To fix this, we add a task that ensures all instruments are recompiled when at least one of them changes.
2020-06-08 14:56:03 +03:00
Annotations are used to register the implemented instruments with Graal. The
annotation processor is triggered when recompiling the Java files.
Unfortunately, when doing an incremental compilation, only the changed files are
recompiled and the annotation processor 'forgets' about other instruments that
haven't been recompiled, leading to runtime errors about missing instruments.
Register instruments/language in their own compilation units to fix the sbt build issues (#3509) New plan to [fix the `sbt` build](https://www.pivotaltracker.com/n/projects/2539304/stories/182209126) and its annoying: ``` log.error( "Truffle Instrumentation is not up to date, " + "which will lead to runtime errors\n" + "Fixes have been applied to ensure consistent Instrumentation state, " + "but compilation has to be triggered again.\n" + "Please re-run the previous command.\n" + "(If this for some reason fails, " + s"please do a clean build of the $projectName project)" ) ``` When it is hard to fix `sbt` incremental compilation, let's restructure our project sources so that each `@TruffleInstrument` and `@TruffleLanguage` registration is in individual compilation unit. Each such unit is either going to be compiled or not going to be compiled as a batch - that will eliminate the `sbt` incremental compilation issues without addressing them in `sbt` itself. fa2cf6a33ec4a5b2e3370e1b22c2b5f712286a75 is the first step - it introduces `IdExecutionService` and moves all the `IdExecutionInstrument` API up to that interface. The rest of the `runtime` project then depends only on `IdExecutionService`. Such refactoring allows us to move the `IdExecutionInstrument` out of `runtime` project into independent compilation unit.
2022-06-13 17:09:08 +03:00
To fix that, individual services have to be placed in separate subprojects
depending on `runtime` and aggregated under `runtime-with-instruments`. Later
the META-INF registrations are concatenated in the final uber jar.
Reference in New Issue Copy Permalink