the owner has removed it!
This fixes the issue by forcing NameDictionary to not transfer
ownership. This means ComponentApplication()::Destroy will fully destroy
the NameDictionary before the OS::Allocator is destroyed.
In Windows the bug was not happening when running AssetProcessorBatch
because for Windows, _exit() is called before the application shutsdown
forcing all module to properly decrease the reference count of
EnvironmentVaqriableHolderBase::m_useCount for NameDictionary.
In MacOS, there's no _exit() so when the NameDictionary destructor was being called
before existing the application the reference count wouldn't be 0, and
would eventually try to destry the NameDictionary BUT the OS::Allocator
was already destroyed.
Signed-off-by: galibzon <66021303+galibzon@users.noreply.github.com>
This change adds a `DomBackend` interface and a `DomBackendRegistry` for backend discovery (currently not hooked up to anything) alongside a JSON backend implementation.
The JSON backend comes with a small suite of unit and performance tests. The unit tests validate generic DOM conversion to and from serialized JSON and rapidjson::Document objects (the support for which lives in `JsonSerializationUtils.h`).
The performance tests show a throughput decrease compared to directly using the rapidjson serializer when mirroring our current pattern of copying strings from the serialized JSON representation, but with the coming in-memory store we have the opportunity to keep the buffer in memory and deserialize in-situ using rapidjson's API, which is consistently at least 100MiB/s faster on my machine (Ryzen Threadripper 3970X). The first parameter is the nested object complexity (N*N, objects with N keys comprised of arrays with N values) and the second parameter is the base size of the strings within each entry of this object.
```
----------------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
----------------------------------------------------------------------------------------------------------------------
DomJsonBenchmark/DomDeserializeToDocumentInPlace/10/5 0.050 ms 0.050 ms 10000 bytes_per_second=355.816M/s
DomJsonBenchmark/DomDeserializeToDocumentInPlace/10/50 0.057 ms 0.057 ms 11200 bytes_per_second=386.064M/s
DomJsonBenchmark/DomDeserializeToDocumentInPlace/100/5 4.77 ms 4.88 ms 112 bytes_per_second=364.046M/s
DomJsonBenchmark/DomDeserializeToDocumentInPlace/100/500 11.6 ms 11.7 ms 64 bytes_per_second=554.518M/s
DomJsonBenchmark/DomDeserializeToDocumentWithCopies/10/5 0.084 ms 0.084 ms 7467 bytes_per_second=212.55M/s
DomJsonBenchmark/DomDeserializeToDocumentWithCopies/10/50 0.099 ms 0.100 ms 6400 bytes_per_second=220.608M/s
DomJsonBenchmark/DomDeserializeToDocumentWithCopies/100/5 8.22 ms 8.16 ms 90 bytes_per_second=217.847M/s
DomJsonBenchmark/DomDeserializeToDocumentWithCopies/100/500 23.2 ms 22.9 ms 30 bytes_per_second=283.56M/s
DomJsonBenchmark/JsonUtilsDeserializeToDocument/10/5 0.070 ms 0.070 ms 11200 bytes_per_second=255.049M/s
DomJsonBenchmark/JsonUtilsDeserializeToDocument/10/50 0.086 ms 0.087 ms 8960 bytes_per_second=253.258M/s
DomJsonBenchmark/JsonUtilsDeserializeToDocument/100/5 6.86 ms 6.84 ms 112 bytes_per_second=260.033M/s
DomJsonBenchmark/JsonUtilsDeserializeToDocument/100/500 22.8 ms 22.9 ms 32 bytes_per_second=283.158M/s
```
For `AZ::DOM::Document`, the current plan is to offer helper methods that can load from a file path or string using a given backend that can take advantage of in-place parsing by internally storing the serialized buffer.
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
Leaving in the print for absorbed asserts to avoid running into future situations where important asserts are accidentally absorbed
Signed-off-by: amzn-mike <80125227+amzn-mike@users.noreply.github.com>
This change was made years ago in CrySystem (see CSystem::HandleMessage in System.cpp), but looks like it never made it into the NativeWindow_Windows version.
Signed-off-by: bosnichd <bosnichd@amazon.com>
- Added support for NDK r23
- Added support for the versioned Android 'cmdline-tools' package which replace the deprecated 'tools' package
- Updated max Gradle version to latest point release of 7.0 to fix volume query bug during sync in some configurations
- Updated min Android Gradle plugin version to latest point release of 4.2
- Fixed issue with Gradle task chaining for some custom copy tasks
- Replaced use of deprecated 'jcenter' repo with 'mavenCentral' in Android project generator template
- Increased debug logging around adb calls in Android deployment script
- Fixed a couple try/except cases that were looking for the wrong exception when invoking adb_* functions
- Fixed issue where asset cache would get deleted when regenerating an existing Android Gradle project with --overwrite-existing
- Fixed issues with running Android project generation scripts on Unix systems
Signed-off-by: AMZN-ScottR 24445312+AMZN-ScottR@users.noreply.github.com
* Enable relocation of the Project Game Release Layout
Relocating the Project Game Release Layout to another directory on the file system failed due to the querying of the engine root failing due to the ComponentApplication::m_engineRoot not using the project path stored in the SettingsRegisry if the engine root cannot be detected
Removed the ApplicationRequestBus GetEngineRoot function.
The ComponentApplicationRequestBus has a function of the same name that returns the same path.
Removed the deprecated GetAppRoot function.
The path it returns has no defined value. It was not the engine root or the project root.
Removed unused CFileUtil and CFileUtil_impl functions that were invoking the ApplicationREquestBus GetEngineRoot function.
On the way to update the functions it was discovered that they aren't called
Added a CalculateBranchToken overload that can populate a fixed_string to avoid heap allocations
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Protect against an empty list of artifacts to remove when generating the
engine.pak
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>