When enabled, WSM writes module xml files immediately when the file content is available (needs less heap because all the intermediate objects will be collected sooner). When disabled (legacy behavior) WSM will collect all the contents of all the files for each changed module, and then flush all the data in a separate pass (needs more heap to keep all the intermediate objects).
GitOrigin-RevId: 4c3756a21f7d1b24fecb798a71d56cd837ba58e1
When enabled, WSM bypasses module's configuration stores on project save and writes module xml files directly to 'cache' directory (iml files are still saved through module's configuration stores)
GitOrigin-RevId: de34f4534b62ebb5bba957651c36e49d9d9bbf3c
The goal is to take full control over iml parsing. Namely:
0. From WSM's point of view, iml/xml files are plain xml files that describe a project, not a component store. There are no components in WSM, there are entities. Partitioning (accessing components by names) is not really helpful here.
1. Get full access to iml/xml file content: soon we'll need a method like `getAllComponents`. Introducing this method to JpsFileContentReader does not look right because this would mean that some code might try parsing the whole config file, instead of querying its own piece of configuration.
2. Do not keep parsed iml files in the memory longer than needed (JpsFileContentReader may hold cached content longer than actually needed).
GitOrigin-RevId: 7461e6a1a0fa539feb025f6f626f224df56be230
Extract duplicated code (which converts module attributes to DeprecatedModuleOptionManager component) into a separate object DefaultImlNormalizer
GitOrigin-RevId: 2ba0939a57331cdeb6c9e8395c962cab1314b30a
This is to improve control over which files are being accessed in ModuleImlFileEntitiesSerializer, and to make it more clear which file (iml or xml) is read in different places
GitOrigin-RevId: 7b11b8caf0acb9ed3eb60e8518360e17d3a0af5f
It does not make sense to replace a value in `entityCache`
if it was concurrently inserted by someone else.
GitOrigin-RevId: f28ff2357ced479942bef3c05483d5106a757d34
This makes the explicit synchronization unnecessary.
In the past, using `ConcurrentLongObjectMap` here led
to performance degradations (see IJPL-14861).
Now performance tests seem to indicate that there is no performance degradation
related to `ConcurrentLongObjectMap` anymore - presumably after a significant update
made to it in ite2c9a0a59.
^IJPL-161667 Fixed
GitOrigin-RevId: f1be39475667cd48de62c1b85c6cef611128fa7d
We have code that invokes `jpsLibrary.getParent().getParent()` to get a JpsModule instance for a module-level library. To keep such code working, we need to have JpsModule and JpsProject as super-parents (not direct parents) of JpsLibrary instances in the new implementation as well.
GitOrigin-RevId: a5f944d152229275b05efdfc686afa091c3fd963
Indexes update may take some time, but there is no need to do it if there are no changes in the entity.
GitOrigin-RevId: cafacff194d6837fbd5d004ca1da81c819c42ed1
StorageSerializerUtil.getVirtualFileUrlSerializer stores VirtualFileUrl instance in completely different format if 'ide.workspace.model.store.relative.paths.in.cache' registry option is enabled. Deserialization in the build process must use the same format as the IDE, so now value of this registry options is passed as 'ide.workspace.model.store.relative.paths.in.cache' system property to the JPS build process and used there to switch relativization on or off.
GitOrigin-RevId: a87b7f4f1a2c073a8d1fdaaa72a38b5dc11d0e01
We have a custom serializer for `VirtualFileUrl` which is used for its implementations. In the IDE process we use `VirtualFileUrlBridge` implementation for all instances, and in the JPS build process this class is not available, and `VirtualFileUrlImpl` is used instead. To avoid mentioning the specific class name in the cache, `VirtualFileUrlManagerImpl` now exposes the implementation class via `virtualFileUrlImplementationClass`, which is registered in Kryo.
This also speeds up serialization a bit since we don't need to iterate over all instances of VirtualFileUrl in the storage.
GitOrigin-RevId: 7366f37cbc7a1575bbc97aba0b45eb4d547974a3
