Basically, some package names were Native-specific, whilst the packages
themselves were not Native-specific at all. This was already reflected
in the directory layout, but not in the package names.
This is fixed here.
NFC, just an automatic rename of packages with fixes of imports.
- add FastJarFS cache cleaning to the daemon implementation, so
the behavior is now the same as for CoreJarFS
- clear not only mappings but also handlers cache: this may result some
slowdown on comparison with the previous cleaning implementation,
but should avoid unreliable behavior on heavy parallel build usages.
FastJarFS was behaving differently than the regular CoreJarFS it
tries to replace, namely it was cleaned after each compilation
(had the lifetime tied to core env).
This commit preserve it in the app env the same way as CoreJarFS,
so it could be reused in parallel builds and preserved if automatic
cleanup of the app env is turned off,
But since FastJarFS caches also mmf handles, the additional handles
cleaning is introduced that triggers after all possibly parallel
compilations are finished.
The latter is used e.g. for scripts in source roots handling
as implemented in the commit
"Scripting: update scripts in source roots handling"
The former implementation did not covered all the cases.
#KT-54355 fixed
Disposer uses passed object identity to decide should it be registered
Since lambda, that passed into disposer doesn't capture anything, it has
only one instance, so it ends up being registered only once
While it should be registered for every parentDisposable
getOrCreateApplicationEnvironment is main entrypoint to create
ApplicationEnvironment in production and compiler tests
It is subject to be called concurrently, that's why
APPLICATION_LOCK exists
ApplicationEnvironment itself hosts Application from idea-core
It is actually singleton, that is subject to be disposed, once all
operations referencing it completes
To properly dispose ApplicationEnvironment when there is no references
left, we maintain reference counter aka ourProjectCount
Originally, there was data-race caused by the fact, that ourProjectCount
was updated after publication of application
Linear, data-race occurs in following order
T1: getOrCreateApplicationEnvironment returns application
T2: Disposes its reference to application, causing ourProjectCount to
reach zero, and disposing application that is already available to T1
T1: Updates counter, but its application already disposed
With new syntax each plugin should be registered in separate argument with syntax
`-Xcompiler-plugin=classpath1,classpath2[=argument1=value1,argument2=value2]`
Andrey Uskov