> V8 VM optimized for that (type dynamics).
> Dart VM has a lot problem with performance with this dynamics

This claim is substantially false. Where are you deriving this "Dart VM has a lot problem..." from? (feel free to respond in Russian). If you actually knew how V8 is implemented you would know that all values in the V8 have something called a hidden class (internally in the sources it's called map) and V8 optimizes based on identity of those hidden classes. This is not that different from the Dart - classes are just not hidden in Dart.

> A lot of (problematic) method in these list. Dart VM code generators and optimizers is unable to optimize usage of them by the Dart VM intelligence.

You are misunderstanding/misrepresenting why these lists exist. Let's talk about them one by one.

1. INTRINSICS Most methods on the intrinsic list don't even have pure-Dart bodies (so there is nothing to optimized with "Dart VM intelligence") and they are on the list for two purposes:

- provide fast hand written assembly implementation, that is more efficient version written in C++;
- tell optimizing compiler how to lower these instructions into IR operations.

Without them being on the list there is no way optimizing compiler can optimize anything - because it would only see a call to some native runtime function with unknown semantics. How is it supposed to understand that _TypedList._getFloat64 is actually a pair of a CheckArrayBound and LoadIndexed<Double>() instructions?

Some of these intrinsified methods do have Dart bodies - but we still provide a hand-written assembly implementation for them. I think these days it's limited to methods of the Bigint class. This is the same in any arbitrary width integer library (e.g. look into GMP sources) - you can write it in C++ but people still write these things in assembly because even C++ can't always produce the best code for this.

2. INLINING_WHITELIST These are the methods that that we know are usually beneficial to inline into the caller's code even if other budget constraints are preventing it. Inlining is a very hard problem in compiler construction - it's impossible to always make optimal decisions given compilation time constraints of the JIT. Even AOT compilers need hints for this, and if you take a random JIT you will discover that it most likely has a similar whitelist built in. Essentially this white list is here precisely because we know that we can optimize this methods very well once they are inlined (which is complete opposite of "cannot be optimized" that you invoke).

3. INLINING_BLACKLIST Similar to whitelist it contains functions that we know are not beneficial to inline. Limited to Bigint class actually now, which is a very special case as explained above.

4. POLYMORPHIC_TARGET_LIST this is utility list that improves the structure of the graph that polymorphic inliner builds (it tells inliner that resulting code would not benefit from merging different branches of the polymorphic call even if they share the same target). None of the methods on this list have an actual Dart body.

To summarize all these lists exist because they encode knowledge that is impossible for Dart VM to get because those properties are essentially algorithmically undecidable.