Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
New code to perform managed <-> java lookups (typemap)
Xamarin.Assembly needs to "translate" managed types to Java types and
vice versa in order to provide a bridge between the two world. So far it
has been done using a straightforward (and fast) method of performing
the lookups - all the type pairs were stored in two tables of the same
size, with all type names padded to the width of the longest name so
that the `bsearch` C function can be used to quickly perform a binary
search over the data set. This approach works very well at the expense
of data size (shorter strings are 0-padded to the maximum width) and a
slightly degraded performace because of the requirement to perform
string comparisons. Furthermore, the lookup required that reflection is
used to obtain full managed type name (when translating from managed to
Java) or to get a `Type` instance from type name (when translating from
Java to managed).
For Release builds all the above data is placed in the
`libxamarin-app.so` library, for Debug builds it is also placed in two
files - one for each direction of lookup, described above.
This commit is a slight improvement over the above scheme. It eliminates
reflection from the process by using managed type tokens (which are
integers) and using UUID/Guid of the module in which the type is found.
This allows us to perform the binary search over the set of 20 bytes (16
bytes for the UUID and 4 bytes for the token ID) for managed to Java
lookups and a single string comparison + binary search over a set of
integers for the Java to managed lookup.
Java type names must still be used because Java doesn't provide any
equivalent to the .NET's type token and module UUID. Those names are
still 0-padded to the width of the longest name but there are no longer
duplicated. Managed type names are eliminated completely.
If Xamarin.Android Instant Run is not used (which is the case for OSS
code) for Debug builds, the operation is performed in the same way for
both Release and Debug builds. If, however, Instant Run is in effect,
the type maps are stored in several files with the .typemap extension -
one per **module**. The files contain both the Java to managed maps as
well as managed to Java maps (which use indexes into the Java to managed
maps). All of those files are loaded during Debug app startup and used
to construct a dataset which is the searched during all the lookups.
Typemap index file format, all data is little-endian:
----
**Header format**
`[Magic string]` # XATI
`[Format version]` # 32-bit unsigned integer, 4 bytes
`[Entry count]` # 32-bit unsigned integer, 4 bytes
`[Module file name width]` # 32-bit unsigned integer, 4 bytes
`[Index entries]` # Format described below, `Entry count` entries
**Index entry format:**
`[Module UUID][File name]<NUL>`
*Where:*
`[Module UUID]` is 16 bytes long
`[File name]` is right-padded with `<NUL>` characters to the `[Module file name width]` boundary.
Typemap file format, all data is little-endian:
----
**Header format**
`[Magic string]` # XATM
`[Format version]` # 32-bit integer, 4 bytes
`[Module UUID]` # 16 bytes
`[Entry count]` # unsigned 32-bit integer, 4 bytes
`[Duplicate count]` # unsigned 32-bit integer, 4 bytes (might be 0)
`[Java type name width]` # unsigned 32-bit integer, 4 bytes
`[Assembly name size]` # unsigned 32-bit integer, 4 bytes
`[Assembly name]` # Non-null terminated assembly name
`[Java-to-managed map]` # Format described below, `[Entry count]` entries
`[Managed-to-java map]` # Format described below, `[Entry count]` entries
`[Managed-to-java duplicates map]` # Map of unique managed IDs which point to the same Java type name (might be empty)
**Java-to-managed map format:**
`[Java type name]<NUL>[Managed type token ID]`
Each name is padded with `<NUL>` to the width specified in the `[Java type name width]` field above.
Names are written without the size prefix, instead they are always terminated with a nul character
to make it easier and faster to handle by the native runtime.
Each token ID is an unsigned 32-bit integer, 4 bytes
**Managed-to-java map format:**
`[Managed type token ID][Java type name table index]`
Both fields are unsigned 32-bit integers, to a total of 8 bytes per entry. Index points into the
`[Java-to-managed map]` table above.
**Managed-to-java duplicates map format:**
Format is identical to `[Managed-to-java]` above.
Size changes (XF integration test, `libxamarin-app.so`, Release build):
----
- armeabi-v7a
- before: 376616
- after: 97860
- arm64-v8a
- before: 377408
- after: 104192
- x86
- before: 376424
- after: 97604
Performance changes (XF integration test, Release build):
----
Device name: **Pixel 3 XL**
Device architecture: **arm64-v8a**
Number of test runs: **10**
| | **Native to managed** | **Runtime init** | **Displayed** | **Notes** |
|-----------------|------------------------|------------------|---------------|--------------------------------|
| **master** | 141.102 | 160.606 | 839.80 | preload enabled; 32-bit build |
| **this commit** | 134.539 | 154.701 | 836.10 | |
| **master** | 141.743 | 158.325 | 837.20 | preload disabled; 32-bit build |
| **this commit** | 134.064 | 149.137 | 831.90 | |
| **master** | 134.526 | 152.640 | 805.10 | preload enabled; 64-bit build |
| **this commit** | 126.376 | 143.226 | 788.60 | |
| **master** | 134.049 | 149.543 | 779.40 | preload disabled; 64-bit build |
| **this commit** | 124.847 | 139.227 | 776.10 | |
Build performance (**Release** build):
----
**Before**
389 ms GenerateJavaStubs 1 calls
**After**
247 ms GenerateJavaStubs 1 calls
New code generates only native assembly or only the binary typemap
files, unlike the old code which generated both. Initially the new
generator code was moved to a separate task, but Jonathan Peppers
determined that it was suboptimal and re-integrated the code back with
`GenerateJavaStubs`- Loading branch information
