| commit | 71f9303dc0131deed737d13d6fac1adb41b4ee71 | [log] [tgz] |
|---|---|---|
| author | Dennis Shen <dzshen@google.com> | Wed Mar 13 17:53:08 2024 +0000 |
| committer | Dennis Shen <dzshen@google.com> | Wed Mar 13 18:10:19 2024 +0000 |
| tree | d8d64aedb16f95deae305d8b7c275ddcca341cde | |
| parent | c7704f165044b89353e28087e167b6766961ae21 [diff] |
aconfig: update aconfig_storage_read_api Right now, aconfig_storage_read_api rust lib would own mapped files. So individual flag lib does not need to. The original intent is that all these flag lib can dynamically link against this lib. So say we have different variants of flag lib for one flag package, there is just one unique memory mapped file. In addition, the exposed rust apis hides the memory mapped files. So when exporting these apis to c++/java, we don't have to implement memory mapping in c++/java flag read api lib. However, this design has its own downside. The biggest being that these memory mapped files are stored in a mutable static hash map. For rust, it must be protected by a mutex lock. The real effect on the lock is mostly minimal as it immediately unlocks when the clone of memory mapping is returned. But still we could get more performance out of it in exchange of having more c++/java side implementation of mapping files. (Note, apis that interpret mapped files are still exported by Rust, so no c++/java implementation needed). In this change, aconfig_storage_read_api give away its ownership of memory mapped file in its api to get memory mapped file. The memory mapped file is supposed to be owned by generated flag lib. By doing so, no more mutex lock is needed. Also, since each flag lib has one flag package, which maps to a single owning container. The flag lib can have the memory mapped files as non mutable static variables. So no mutex lock penalty on flag lib side. Bug: b/321077378 Test: atest aconfig_storage_read_api.test; atest aconfig_storage_read_api.test.rust Change-Id: I29060bae90db6f7d296252ed73f7e312143f4b7e
This is the Makefile-based portion of the Android Build System.
For documentation on how to run a build, see Usage.txt
For a list of behavioral changes useful for Android.mk writers see Changes.md
For an outdated reference on Android.mk files, see build-system.html. Our Android.mk files look similar, but are entirely different from the Android.mk files used by the NDK build system. When searching for documentation elsewhere, ensure that it is for the platform build system -- most are not.
This Makefile-based system is in the process of being replaced with Soong, a new build system written in Go. During the transition, all of these makefiles are read by Kati, and generate a ninja file instead of being executed directly. That's combined with a ninja file read by Soong so that the build graph of the two systems can be combined and run as one.