Moving tests to another package made the IDEA run configuration obsolete.
To prevent this problem in the future a separate task (jsStdlibApiTest)
was introduced. The task is run in TC and will fail if the tests are missing.
Merge-request: KT-MR-8128
Merged-by: Abduqodiri Qurbonzoda <abduqodiri.qurbonzoda@jetbrains.com>
This should solve the problem with deadlocks/performance in the K2 IDE
This is a temporary solution until the ^KT-55387 is properly fixed
^KT-55387
^KT-54890
This commit makes the compiler read the pre-release flag from loaded
klibs. Now the K1 frontend checks this flag in
MissingDependencyClassChecker checker, reporting errors if the current
compiler configuration doesn't allow using pre-release dependencies.
^KT-54905 Fixed
JsAllowValueClassesInExternals language feature had UNSTABLE_FEATURE
kind and was enabled by default for JS IR backend. As a result, klibs
compiled with recent compiler versions were marked with the pre-release
flag.
Now, if we enabled reading the flag from klibs, the JS IR compiler would
reject all these klibs by default. To fix that, this commit changes the
flag value from 0x1 to 0x2, so that all previously compiled klibs are
treated as not having the pre-release flag.
When a language feature has UNSTABLE_FEATURE kind, enabling it causes
the compiler to mark the compiled library with the pre-release flag.
JsAllowValueClassesInExternals feature is enabled by default in JS IR
backend. So effectively, all JS klibs are marked with the pre-release
flag. This remained unnoticed because the compiler currently doesn't
read this flag from klibs. This will change soon.
To fix the problem, this commit changes the feature kind to OTHER, which
doesn't enforce the pre-release flag.
No clue where to put the test for that since diagnostic tests, even
multi-module ones, never touch the metadata serializer. So the test is
a bytecode text one pretending to be about nullability annotations even
though it also affects what resolution in another module will do.
This change avoids looping through the source stack, looking for the
last element, in the case where the target stack is empty. This could
matter in two places:
* when merging ready_ and used_ into unswept_ in PrepareForGC. The first
of these will be faster with this change.
* when merging finalizer queues (in CR-592, not merged yet), where we
expect the target queue to be empty.
Since we can expect used_ to be larger than ready_, since we are about
to do a GC, the order of these two has also been reversed.
Co-authored-by: Troels Lund <troels@google.com>
Merge-request: KOTLIN-MR-599
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
The default behavior on a sweep is to push empty pages into a separate
stack, which will be freed if not used before the next GC starts. This
serves two purposes: it reduces the number of system allocations, and it
avoids a race condition inside AtomicStack::Pop.
Neither of these are relevant for LargePages, since LargePages are never
reused and it is only the GC thread that calls
AtomicStack<LargePage>::Pop. The change is to free LargePages
immediately instead of waiting for the next GC cycle.
Co-authored-by: Troels Lund <troels@google.com>
Merge-request: KOTLIN-MR-598
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
Current workaround is not working with platform (bom) and since 1.8.0
release kotlinx-serialization was migrated to IR which removed need for
workaround.
^KT-54691 In Progress
Nikolay Lunyak