Files

T

Daco Harkes 8de00e2137 [vm] Introduce pragma vm:deeply-immutable

This CL introduces a way to mark all instances of a class as deeply
immutable.

In order to statically verify that all instances of a deeply immutable
class are immutable, a deeply immutable classes must have the following
properties:

1. All instance fields must
   1. have a deeply immutable type,
   2. be final, and
   3. be non-late.
2. The class must be `final` or `sealed`. This ensures no
   non-deeply-immutable subtypes are added by external code.
3. All subtypes must be deeply immutable. This ensures 1.1 can be
   trusted.
4. The super type must be deeply immutable (except for Object).

Note that instances of some classes in the VM are deeply immutable
while their class cannot be marked immutable.

* SendPort, Capability, RegExp, and StackTrace are not `final` and
  can be implemented by external code.
* UnmodifiableTypedDataViews do not have a public type. (It was
  recently deprecated.)

See runtime/docs/deeply_immutable.md for more details.

Use case:

This enables attaching a `Dart_FinalizableHandle` to a deeply immutable
object and the deeply immutable object with other isolates in the same
isolate group.

(Note that `NativeFinalizer`s live in an isolate, and not an isolate
group. So this should currently _not_ be used with `NativeFinalizer`s.
See https://github.com/dart-lang/sdk/issues/55062 for making a
`NativeFinalizer.shared(` that would live in an isolate group instead
of in an isolate.)

Implementation details:

Before this CL, the `ImmutableBit` in the object header was only ever
set to true for predefined class ids (and for const objects). After
this CL, the bit can also be set to true for non const instances of
user-defined classes. The object allocation and initialization code has
been changed to deal with this new case. The immutability of a class is
saved in the class state bits. On object allocation and initialization
the immutability bit is read from the class for non-predefined class
ids.

TEST=runtime/tests/vm/dart/isolates/fast_object_copy2_test.dart
TEST=runtime/vm/isolate_reload_test.cc
TEST=tests/lib/isolate/deeply_immutable_*

Bug: https://github.com/dart-lang/sdk/issues/55120
Bug: https://github.com/dart-lang/sdk/issues/54885
Change-Id: Ib97fe589cb4f81673cb928c93e3093838d82132d
Cq-Include-Trybots: luci.dart.try:vm-aot-android-release-arm64c-try,vm-aot-android-release-arm_x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-appjit-linux-debug-x64-try,vm-asan-linux-release-x64-try,vm-checked-mac-release-arm64-try,vm-eager-optimization-linux-release-ia32-try,vm-eager-optimization-linux-release-x64-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-ffi-qemu-linux-release-arm-try,vm-ffi-qemu-linux-release-riscv64-try,vm-fuchsia-release-x64-try,vm-kernel-linux-debug-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-linux-debug-ia32-try,vm-linux-debug-x64-try,vm-linux-debug-x64c-try,vm-mac-debug-arm64-try,vm-mac-debug-x64-try,vm-msan-linux-release-x64-try,vm-reload-linux-debug-x64-try,vm-reload-rollback-linux-debug-x64-try,vm-ubsan-linux-release-x64-try
Cq-Include-Trybots: dart-internal/g3.dart-internal.try:g3-cbuild-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354902
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>

2024-03-07 18:33:58 +00:00

6.0 KiB

Raw Blame History

VM-Specific Pragma Annotations

Pragmas for general use

These pragmas are part of the VM's API and are safe for use in external code.

Pragma	Meaning
`vm:entry-point`	Defining entry-points into Dart code for an embedder or native methods
`vm:never-inline`	Never inline a function or method
`vm:prefer-inline`	Inline a function or method when possible
`vm:notify-debugger-on-exception`	Marks a function that catches exceptions, making the VM treat any caught exception as if they were uncaught. This can be used to notify an attached debugger during debugging, without pausing the app during regular execution.
`vm:keep-name`	Will ensure we keep the name of the class/function - even if e.g. obfuscation mode is enabled.
`vm:external-name`	Allows to specify an external (native) name for an `external` function. This name is used to lookup native implementation via native resolver associated with the current library through embedding APIs. This is a replacement for legacy VM specific `native "name"` syntax.
`vm:invisible`	Allows to mark a function as invisible so it will not appear on stack traces.
`vm:always-consider-inlining`	Marks a function which particularly benefits from inlining and specialization in context of the caller (for example, when concrete types of arguments are known). Inliner will not give up after one failed inlining attempt and will continue trying to inline this function.
`vm:platform-const`	Marks a static getter or a static field with an initializer where the getter body or field initializer evaluates to a constant value if the target operating system is known.
`vm:platform-const-if`	Like `vm:platform-const`, but takes a boolean argument and constant evaluation of the annotated member is only performed if the argument const evaluates to true.
`weak-tearoff-reference`	Declaring a static weak reference intrinsic method.
`vm:isolate-unsendable`	Marks a class, instances of which won't be allowed to be passed through ports or sent between isolates.
`vm:awaiter-link`	Specifying variable to follow for awaiter stack unwinding
`vm:deeply-immutable`	Specifying a class and all its subtypes are deeply immutable

Unsafe pragmas for general use

These pragmas are available for use in third-party code but are potentially unsafe. The use of these pragmas is discouraged unless the developer fully understands potential repercussions.

Pragma	Meaning
`vm:unsafe:no-interrupts`	Removes all `CheckStackOverflow` instructions from the optimized version of the marked function, which disables stack overflow checking and interruption within that function. This pragma exists mainly for performance evaluation and should not be used in a general-purpose code, because VM relies on these checks for OOB message delivery and GC scheduling.

Pragmas for internal use

These pragmas can cause unsound behavior if used incorrectly and therefore are only allowed within the core SDK libraries.

Pragma	Meaning
`vm:exact-result-type`	Declaring an exact result type of a method
`vm:recognized`	Marking this as a recognized method
`vm:idempotent`	Method marked with this pragma can be repeated or restarted multiple times without change to its effect. Loading, storing of memory values are examples of this, while reads and writes from file are examples of non-idempotent methods. At present, use of this pragma is limited to driving inlining of force-optimized functions.
`vm:cachable-idempotent`	Functions marked with this pragma will have their call site cache the return value. Not supported in ia32. Call site must have the pragma `vm:force-optimze`.
`vm:force-optimze`	Functions marked with this pragma will be compiled with the optimized pipeline and may not deoptimize.

Pragmas ignored in user code

These pragma's are only used on AST nodes synthesized by us, so users defining these will be ignored.

Pragma	Meaning
`vm:ffi:call-closure`	Closure performing FFI calls
`vm:ffi:native-assets`	Passing a native assets mapping to the VM
`vm:ffi:native`	Passing a native arguments to the VM

Pragmas for internal testing

These pragmas are used for inspecting or modifying internal VM state and should be used exclusively by SDK tests. They must be enabled with the --enable-testing-pragmas flag. The names of these pragmas are prefixed with "testing". Additionally, they are categorized into "safe" and "unsafe" forms: "safe" pragmas should not affect the behavior of the program and can be safely added anywhere, whereas "unsafe" pragmas may change the code's behavior or may cause the VM to crash if used improperly.

Pragma	Meaning
`vm:testing.unsafe.trace-entrypoints-fn`	Observing which flow-graph-level entry-point was used when a function was called

Flutter toString transformer pragmas

These pragmas are useful to exclude certain toString methods from toString transformation, which is enabled with --delete-tostring-package-uri option in kernel compilers and used by Flutter to remove certain toString methods in release mode to reduce size.

Pragma	Meaning
`flutter:keep-to-string`	Avoid transforming the annotated toString method.
`flutter:keep-to-string-in-subtypes`	Avoid transforming toString methods in all subtypes of the annotated class.

6.0 KiB Raw Blame History