[vm] Store compression info during GC visit macros.

-----

Adds a few type traits for operating on (Compressed)ObjectPtr types:

* is_compressed_ptr<T>::value is true for compressed pointer types and
  false for uncompressed pointer types.
* is_uncompressed_ptr<T>::value is false for compressed pointer types
  and true for uncompressed pointer types.
* base_ptr_type<T>::type is ObjectPtr for uncompressed pointer types and
  CompressedObjectPtr for compressed pointer types.

Note: If DART_COMPRESSED_POINTERS is not enabled, all pointers are
uncompressed and the above traits function accordingly. That means
that is_compressed_ptr<T>::value is always false,
is_uncompressed_ptr<T>::value is true for all object pointers, and
base_ptr_type<T>::type is ObjectPtr for all object pointers, even if
they contain Compressed in the name.

-----

The following changes have been made to the VISIT_* macros:

* VISIT_NOTHING: no change.
* VISIT_FROM: takes only a field name now, and retrieves the type of
  the field to determine which base pointer type to use for from().
  Note that VISIT_FROM must now come _after_ the declaration of the
  field, since it retrieves the type from the declaration.
* VISIT_TO: takes only a field name now, and retrieves the type of the
  field to determine which base pointer type to use for to().
* (removed) VISIT_TO_LENGTH: Instead, VISIT_TO creates a to() method
  that takes an optional length argument (defaults to 0).
* (new) VISIT_FROM_PAYLOAD_START: takes the object pointer type of the
  payload elements and creates a from() that returns the beginning
  element of the payload. Note that a payload element must be a single
  object ptr to use this macro.
* (new) VISIT_TO_PAYLOAD_END: takes the object pointer type of the
  payload elements and creates a to() which takes a non-optional length
  argument and returns the last element of the payload.  Note that a
  payload element must be a single object ptr to use this macro.

If one of the {COMPRESSED_,}VARIABLE_POINTER_FIELDS macros are used,
then VISIT_TO_PAYLOAD_END should not be, as those macros already
include a use of it.

-----

In addition, each Untagged<Class> class now has a static constexpr bool
field kContainsCompressedPointers. This field is false for
UntaggedObject, and for other Untagged<Class> classes, it is either
inherited from the parent class or set during VISIT_FROM and the new
VISIT_FROM_PAYLOAD_START macro.

VISIT_TO and the new VISIT_TO_PAYLOAD_END macro double-check at compile
time that the type retrieved or provided is a compressed type if
kContainsCompressedPointers is true, and uncompressed if false.

If the elements of a payload are not object pointers, but rather
a composite object that contains object pointers, then
VISIT_FROM_PAYLOAD_START/VISIT_TO_PAYLOAD_END cannot be used. Instead,
use DEFINE_COMPRESSED_POINTERS(type), where type is the type of one of
the object pointers in the composite object, to appropriately define
kContainsCompressedPointers.

Note that this field will always be false when DART_COMPRESSED_POINTERS
is not defined.

-----

For classes, a static constexpr ContainsCompressedPointers() predicate
is created, based on the associated untagged class's field.

For instances of Class, there is an instance predicate
Class::HasCompressedPointers() that returns whether instances of a given
class object contain compressed pointers.

Change all calls to InitializeObject and Object::Allocate to pass in
the result of the appropriate predicate.

TEST=Refactoring, so current tests on CI, especially on x64c trybots.

Cq-Include-Trybots: luci.dart.try:vm-kernel-linux-debug-x64c-try,vm-kernel-precomp-linux-debug-x64c-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-linux-debug-x64-try
Change-Id: Ifb61f72885bd8b951167becbccf8ec3337a922b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196931
Reviewed-by: Liam Appelbe <liama@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
5 files changed
tree: 80e0d5be82e4db853a39a4a529662dc17923a531
  1. .dart_tool/
  2. .github/
  3. benchmarks/
  4. build/
  5. client/
  6. docs/
  7. pkg/
  8. runtime/
  9. samples/
  10. samples-dev/
  11. samples_2/
  12. sdk/
  13. tests/
  14. third_party/
  15. tools/
  16. utils/
  17. .clang-format
  18. .gitattributes
  19. .gitconfig
  20. .gitignore
  21. .gn
  22. .mailmap
  23. .packages
  24. .style.yapf
  25. .vpython
  26. AUTHORS
  27. BUILD.gn
  28. CHANGELOG.md
  29. codereview.settings
  30. CONTRIBUTING.md
  31. DEPS
  32. LICENSE
  33. PATENT_GRANT
  34. PRESUBMIT.py
  35. README.dart-sdk
  36. README.md
  37. sdk_args.gni
  38. WATCHLISTS
README.md

Dart

A client-optimized language for fast apps on any platform

Dart is:

  • Optimized for UI: Develop with a programming language specialized around the needs of user interface creation.

  • Productive: Make changes iteratively: use hot reload to see the result instantly in your running app.

  • Fast on all platforms: Compile to ARM & x64 machine code for mobile, desktop, and backend. Or compile to JavaScript for the web.

Dart's flexible compiler technology lets you run Dart code in different ways, depending on your target platform and goals:

  • Dart Native: For programs targeting devices (mobile, desktop, server, and more), Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an AOT (ahead-of-time) compiler for producing machine code.

  • Dart Web: For programs targeting the web, Dart Web includes both a development time compiler (dartdevc) and a production time compiler (dart2js).

Dart platforms illustration

License & patents

Dart is free and open source.

See LICENSE and PATENT_GRANT.

Using Dart

Visit dart.dev to learn more about the language, tools, and to find codelabs.

Browse pub.dev for more packages and libraries contributed by the community and the Dart team.

Our API reference documentation is published at api.dart.dev, based on the stable release. (We also publish docs from our beta and dev channels, as well as from the primary development branch).

Building Dart

If you want to build Dart yourself, here is a guide to getting the source, preparing your machine to build the SDK, and building.

There are more documents on our wiki.

Contributing to Dart

The easiest way to contribute to Dart is to file issues.

You can also contribute patches, as described in Contributing.