Instead of keeping offsets of bytecode declarations in a map,
offset is now stored in a field of a base class for all declarations.
This saves certain number of map lookups while serializing bytecode.
Also, calls to a rather expensive Map.putIfAbsent are removed.
Change-Id: I036fbb0e1d8afc6e402709a0a1eafb0e50a2c25a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122170
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
In order to support obfuscation, string constants are decoupled
from public names in bytecode (names are obfuscated, but string
constants aren't). List of protected names is written in a separate
section in bytecode component.
Obfuscator is extended to support getter and setter
names coming from bytecode.
Change-Id: I8e8d820d1a8b97e32e8ad1b064b827bdb017430b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121261
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
AOT transformations add vm.direct-call.metadata with devirtualization
information to AST nodes.
Bytecode generator should take this information into account when
generating bytecode in case of AOT. Bytecode format is extended with
CheckReceiverForNull and UncheckedDirectCall instructions, and
DirectCallViaDynamicForwarder constant pool entry in order to represent
devirtualized calls.
Change-Id: I697432ddd0b58d2d0413715132ba5e90eb606ec1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119201
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
VM no longer relies on distinct ICData entries in constant pool, and
it no longer creates actual ICData objects.
This change introduces new DynamicCall constant pool entry which is
* de-duplicated;
* stores arguments descriptor inline instead of allocating a separate
constant pool entry and referencing it by index;
* reserves extra slot in constant pool (like other call constants), so
we can eventually remove creation of extra UnlinkedCall objects.
Change-Id: I8d21954803ca5be5b6fc8335b700e8a9086245cf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116120
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
* Type arguments are moved to global object table (and de-duplicated).
* Finalize non-recursive generic types at bytecode generation time.
* Constants are moved to global object table (and de-duplicated).
* ICData creation is avoided for direct calls.
* Interface calls reference target member instead of selector name.
Size of a dilp files: 17868K => 15896K (-11%).
Change-Id: I0c9bf338137a0fae6ed90ab6b125ed2b24a1a8ad
Reviewed-on: https://dart-review.googlesource.com/c/91108
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Dispatch interface calls via hashtable rather than inline cache.
InterfaceCall doesn't need to take arguments descriptor into account
when doing method lookup.
Change-Id: I30eae6ea638d1d2ad2cf3ff073c653fee3377f31
Reviewed-on: https://dart-review.googlesource.com/c/86106
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
This is a major revamp of bytecode metadata format. Now bytecode has
its own serialization mechanisms.
This CL adds 'bytecode component' metadata, which contains bytecode
object table and string table. All references from bytecode (constant
pools) to libraries, classes, members, types and strings now have a new
format. References to frequently used objects are represented as indices
in object table, while rarely used objects are written inline.
This allows VM to cache frequently used objects while reading bytecode.
Representation of strings is aligned with VM - string characters are
stored in separate pools of one-byte and two-byte strings. This allows
VM to avoid UTF-8 decoding and extra copying.
Closure declarations are now explicit. Type parameters no longer require
enslosing scopes when reading/writing them.
Benchmarks:
GenKernelKernelReadAllBytecode (Intel Core i5) +29.84%
GenKernelKernelReadAllBytecode (Intel Xeon) +28.74%
Change-Id: I4b80009733a8f8c038264af74f97c4e094b9e311
Reviewed-on: https://dart-review.googlesource.com/c/85469
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
This CL adds support for _dynamic_ calls (which are routed through
dynamic invocation forwarders) to bytecode pipeline.
This allows to skip argument type checks for non-covariant and
non-generic-convarint-impl parameters in bytecode when calling instance
members through known interface targets. In case of dynamic call, dynamic
invocation forwarders perform type checks which are otherwise skipped.
This CL also corrects argument type checks in forwarding stubs.
Forwarding stubs are synthetic methods, introduced by front-end to ensure
type safety if some of the argument type checks are skipped.
The specifics of forwarding stubs is that they should use parameter types
of a *target* of a stub for the argument type checks.
This change unifies how argument type checks are performed in bytecode
and in the VM in JIT mode. This allows to mix bytecode methods with
methods JIT-compiled from kernel AST in more cases.
Change-Id: I3a2720a488c8bbb91de1b189eb36ee8c51684a78
Reviewed-on: https://dart-review.googlesource.com/72543
Reviewed-by: Samir Jindel <sjindel@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Now, instead of generating Symbol constant pool entries, bytecode generator
uses kernel-to-kernel constant evaluator to evaluate symbol literals.
Change-Id: I8dae4e388b6c1e8158ce39da792bb2e1cea2687a
Reviewed-on: https://dart-review.googlesource.com/69900
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
As TypeArguments == null means 'vector of all dynamic', VM uses special
object (Object::empty_type_arguments()) to indicate absence of
_Closure._delayed_type_arguments.
This CL corrects bytecode to use Object::empty_type_arguments() (via new
constant pool entry EmptyTypeArguments) to initialize
_Closure._delayed_type_arguments when allocating a closure.
Change-Id: I9b00bc0606de85c02350c8eef08d8952c3e224ee
Reviewed-on: https://dart-review.googlesource.com/69840
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Constant pool:
* Field constant pool entry is renamed to StaticField
* FieldOffset constant pool entry is replaced with InstanceField.
InstanceField occupies 2 slots for field offset and field object.
* ContextOffset constant pool entry is removed.
* TypeArgumentsFieldOffset is renamed to TypeArgumentsField
Bytecodes:
* LoadFieldTOS and StoreFieldTOS require InstanceField entry.
* New bytecodes added: LoadContextParent, StoreContextParent,
LoadContextVar, StoreContextVar, LoadTypeArgumentsField.
This CL is a preparation for compilation of bytecodes related
to instance field accesses.
Change-Id: I1d6274e94bd7cd764e4fc83d9847daf4f21e5a25
Reviewed-on: https://dart-review.googlesource.com/68843
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Before this change, ConstantClosureFunction was holding a clone of original
FunctionNode without body (in order to omit body during serialization).
It is not correct: original FunctionNode, which is used to generate
closure's bytecode may reference original type parameters and those
type parameters could be used in types written into constant pool.
A cloned FunctionNode has its own cloned copies of type parameters
and it does not provide a sufficient serialization/deserialization context.
This resulted in 'Type parameter T is not indexed' errors.
This CL fixes this problem by removing cloning. In order to avoid
serialization of the FunctionNode body, body is temporarily dropped
while writing ConstantClosureFunction.
Also, this CL fixes type finalization of signature types of closure functions
read from bytecode. If signature type is not finalized, VM crashes with
'../../runtime/vm/object.cc: 18580: error: expected: IsFinalized()'.
Change-Id: Id88e99609ee387352fc011a8c297024d05e24037
Reviewed-on: https://dart-review.googlesource.com/67960
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This includes argument type checks and implicit type checks inserted
by front-end.
Also, lookup of getter functions is fixed for StaticICData constant
pool entry to include non-static getters (StaticICData is used for
all kinds of direct calls including super calls).
Change-Id: Ic265ea6a7fca2bfcc9a96e4ede268ec8e693ff41
Reviewed-on: https://dart-review.googlesource.com/60822
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Implicit argument for type arguments vector is not counted
in the number of arguments in ArgumentsDescriptor when calling
generic functions, but VM requires it to be counted
when calling factory constructors.
Bytecode generator is adjusted to cope with this discrepancy.
Change-Id: Id041563dfc68491b87593bcb6dff5cae64bfedc6
Reviewed-on: https://dart-review.googlesource.com/58961
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Library reference is added for private names in order to resolve them correctly.
Invocation kind byte supersedes VM-specific name mangling and makes
ConstantICData more uniform with ConstantStaticICData.
Change-Id: I66542356209d98b3d0cf0e6b8eb19bda052c6b7e
Reviewed-on: https://dart-review.googlesource.com/57485
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Metadata is no longer written ahead of all nodes. Instead, metadata for
each node is written in the same context as the node itself (into a separate
buffer). This allows metadata to contain (serialize) arbitrary nodes
(for example, arbitrary DartTypes) and use serialization context of parent
nodes (such as declared type parameters).
However, with this change metadata looses the ability to reference
arbitrary AST nodes. This ability was overly restricted and had no
practical uses. (It was not possible to reference nodes which are not
reachable from root Component. As a consequence, it was not possible to
write references to arbitrary DartTypes.)
This change aligns the serialization capabilities of metadata with
how kernel AST nodes are serialized.
Change-Id: I027299a33b599b62572eccd4aa7083ad1dd2b3b3
Reviewed-on: https://dart-review.googlesource.com/54481
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
While generating bytecode, avoid flattening of type arguments used for
instance allocations (and thus avoid creating new types when substituting
type parameters). This is a workaround to limitation of kernel metadata
which is unable to serialize references to nodes (such as DartType)
not reachable from root Component.
Change-Id: I52c5e21873d0159d389895dc570a9e7283f2a6ff
Reviewed-on: https://dart-review.googlesource.com/52643
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
To enable bytecode generation, toggle kEnableKernelBytecode flag at
the beginning of pkg/vm/lib/bytecode/gen_bytecode.dart.
This will also enable generation of bytecode in platform dill files.
Also, bytecode generation can be enabled using --gen-bytecode option of
pkg/vm/tool/gen_kernel.
In kernel binaries, the generated bytecode and constant pool are
placed into 'vm.bytecode' metadata attached to members.
pkg/vm/tool/dump_kernel tool can be used to disassemble
bytecode and print constant pool.
Differences between generated bytecode and original DBC are
described in pkg/vm/lib/bytecode/dbc.dart.
Format of constant pool is described in
pkg/vm/lib/bytecode/constant_pool.dart.
Currently, only a small subset of Dart language is supported.
Bytecode generator will not emit vm.bytecode metadata for a
member if its body has an unsupported operation.
Change-Id: I27d9a361dc779ea115e5676508ee757c1754e05d
Reviewed-on: https://dart-review.googlesource.com/49600
Reviewed-by: Samir Jindel <sjindel@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Alexander Markov