Use metadata tokens instead of strings to find types and methods.
This makes the code to find methods more compact (a lot less strings in the
executable, and additionally in most cases a compact representation (32-bit
integer) of the corresponding metadata token and additional information can be
used, which results in less executable code (fewer parameters to methods,
etc)), resulting in smaller executables.
Size savings are around 200kb for dont link apps, and 20-60kb for linked apps
(this obviously varies a lot depending on how much has to registered by the
registrar).
| | Before | After | Diff |
|----------------|--------------:|--------------:|------------------:|
| dontlink/32bit | 102.810.144 | 102.609.456 | -200.688 = -0,20% |
| dontlink/64bit | 107.420.576 | 107.221.792 | -198.784 = -0,19% |
| linksdk/32bit | 40.957.296 | 40.936.864 | -20.432 = -0,05% |
| linksdk/64bit | 43.113.136 | 43.093.936 | -19.200 = -0,04% |
| linkall/32bit | 38.410.032 | 38.348.288 | -61.744 = -0,16% |
| linkall/64bit | 40.315.200 | 40.267.344 | -47.856 = -0,12% |
Additionally I've removed the `lazy_map` dictionary, which we populated at
startup and was used to map between Class instances and the corresponding
managed type's FullName, and instead iterate over a native array of Class ->
metadata token mappings whenever we need to look up the managed type for a
certain Class instance.
This is slightly slower for each type we need to look up (for a non-linked app
there might be a 2000-3000 entries in the native array, which would be
iterated instead of using a hashtable lookup), but it's only done once per
type and there's a significant startup memory improvement.
For a non-linked test app I get the following using the Xamarin profiler:
| | Before | After | Diff |
|-------------------|--------:|--------:|----------------:|
| Memory allocated | 2,8 MB | 2,4 MB | -0,4 MB = -14 % |
| Objects allocated | 43678 | 38463 | -5215 = -12 % |
| Private bytes | 26,6 MB | 24,4 MB | -2,2 MB = -8,3% |
| Working set | 26,6 MB | 24,4 MB | -2,2 MB = -8,3% |
Right now the logic exists in a few places, both in and outside the
linker. We recently began to use part of the linker pipeline in normal /
all builds so it's easier to share (and unify) the code now.
The real gain is to avoid copying assemblies, in particular large ones,
more than strictly needed while building.
E.g. a build including a very large 1.3GB assembly, with several
native libraries embedded, save a lot of time avoiding the rewrites
mtouch (before)
Total time: 64202 ms
mtouch (after)
Total time: 34840 ms
* Add XM support for RemoveUserResourcesSubStep
* Tests supplied by @chamons
* Comment is wrong: the code is never executed in parallel
* If reached then RemoveResources will be called and already check for
symbols (and load them when needed). Just a simplification (it won't
really save time as it's not loaded twice)
* [mtouch] Add missing HasParameters check inside linker and static registrar
Without the checks new, empty collections can be allocated and their
whole and only purpose will be to iterate up to 0 (nop).
The checks saves a small amount of memory (collections) and time.
* [registrar] Fix method comparison when they have no parameters
Managed exception marshaling interferes with the debugger, because it adds
exception handlers to executing code, which makes the Mono runtime think an
exception is handled when logically it's not (although technically it is).
The consequence is that the IDEs will only be notified when we re-throw the
exception after catching it, making it impossible for the IDEs to stop when
the exception is thrown (they will instead stop when we re-throw the
exception).
So disable managed exception marshaling (unless the user changed the default
behavior) when a debugger is attached.
This is the same behavior as Xamarin.Android.
https://bugzilla.xamarin.com/show_bug.cgi?id=45116
This makes it possible to set linker flags per assembly:
[assembly: LinkWith (LinkerFlags = "-lsqlite3")]
Which is required when incremental builds is enabled and a particular assembly
needs special linker flags (because we don't propagate the global -gcc_flags
to each dylib we build when doing incremental builds).
Also add an option to set the dlsym mode for an assembly (using the LinkWith
attribute).
Duration before: 1,60s
Duration after: 1,54s
Difference: -0,06s = -3,8%
Memory usage hardly changed (-21 kb of 540 MB), but the number of method calls
shrunk significantly.
Method calls before: 86.720.379
Method calls after: 74.390.061
Difference: -12.330.318 = -14,2%
The call to `GetSystemVoidType` was #2 on the list of method calls (whens
sorted by 'self'), called 1072 times taking 1429 ms each time. After this
change it's only called once (and obviously pushed way down the list).
Fix NullReferenceException in PInvoke wrapper generation when incremental
builds are enabled and the linker didn't run because cached results were
found.
https://bugzilla.xamarin.com/show_bug.cgi?id=44763
* [tests] Remove Classic SDK tests.
* Remove XI/Classic support.
This also means we can remove support for the legacy registrars.
* [monotouch-test] Remove legacy registrar tests.
* [tests/mtouch] Remove Classic tests (and legacy registrar logic).
* [tests/scripted] Fix tests to reference Xamarin.iOS.dll.
We need to compile the generated P/Invoke wrappers to a dylib, and link the
dylib for the product assembly (Xamarin.WatchOS.dll) with the generated
P/Invoke wrappers.
Since there might be P/Invokes in any assembly, just link in the P/Invoke
wrapper dylib for every assembly.
https://bugzilla.xamarin.com/show_bug.cgi?id=44048
note: AVFoundation is commented on watchOS 3 as this breaks the static
registrar .a helper built for watchOS.
AVFoundation does a file check to enable some types - but the watchSimulator
include that file, leading to compilation errors later (missing CMTime.h)
#if TARGET_OS_WATCH
#if ! __has_include(<AVFoundation/AVAnimation.h>)
#define AVF_IS_WATCHOS_SDK 1
#endif
#endif
* Bump [watch-]mono to master to get fix for #43658.
https://bugzilla.xamarin.com/show_bug.cgi?id=43658
* [mtouch/mmp] Fix build after breaking cecil update in mono.
Also use mono's cecil instead of our own cecil submodule for mtouch.
* Bump [watch-]mono to get compilation fixes after cecil bump in mono.
* Remove cecil submodule, we only use the one in mono now.
* Enable some SceneKit-related WatchKit API
* Enable some SceneKit-related SpriteKit API
* Enable some SceneKit-related Foundation API
* Fix generator to include `using SceneKit;` on watchOS
* Adjust xtro tests since watchOS headers include some stuff that's not available in reality
* Lots of [Watch (3,0)] attributes
This is only applicable to tvOS 10 (i.e. the xcode8 branch),
but applying the patch already helps avoiding merge failures
for other fixes in the same area.
Category methods are exposed like extension methods, and the first parameter
specifies the class, which means we need to skip the first type when generating
the ObjC signature.
https://bugzilla.xamarin.com/show_bug.cgi?id=42489
There can be circular dependencies between Objective-C classes,
so make sure we don't fail compilation when that occurs by
forward declaring any Objective-C classes/protocols.
The test case in question does not contain a circular dependency,
but the same issue occurs due to types not being generated in the
correct order (a correct order could be constructed for the test
case, but there's no general solution since circular dependencies
can exist).
https://bugzilla.xamarin.com/show_bug.cgi?id=42454
Category methods are exposed like extension methods, and the first parameter
specifies the class, which means we need to skip the first type when generating
the ObjC signature.
https://bugzilla.xamarin.com/show_bug.cgi?id=42489
There can be circular dependencies between Objective-C classes,
so make sure we don't fail compilation when that occurs by
forward declaring any Objective-C classes/protocols.
The test case in question does not contain a circular dependency,
but the same issue occurs due to types not being generated in the
correct order (a correct order could be constructed for the test
case, but there's no general solution since circular dependencies
can exist).
https://bugzilla.xamarin.com/show_bug.cgi?id=42454
Fixes NSCharacterSetTest.NSMutableCharacterSet_TestStaticSets when
running with the P/Invoke wrapper (for exceptions) enabled (i.e.
watchOS), since otherwise the wrapper would truncate char parameters
to byte.
* Added Speech Framework bindings
* Ensured introspection test pass
* Ensured we link against Speech framework
* FIXME: SFSpeechRecordingRecognitionRequest is not in the public api
filled radar://26799291 https://trello.com/c/s6s6YKua
* Added CallKit Bindings
* Ensure CallKit.framework is linked
* Ensure CallKit passes introspection tests
* FIXME: https://trello.com/c/afWXDZ3A
Headers says CallKit is available on macOS 10.12
but uses AVAudioSession and it is iOS only
Opened Radar awaiting response.
There's a clang bug [2] where if a selector is marked as unavailable,
it's marked as unavailable for every class, not just the class where
the unavailable selector is.
This means that we can't do `[super initWithCoder:x]` anywhere,
because `initWithCoder:` is marked as unavailable for UIActivityViewController.
So instead rewrite the call to super to call objc_msgSendSuper
directly, circumventing clang's broken availability checks.
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=41319
[2] https://llvm.org/bugs/show_bug.cgi?id=28058
mtouch only uses Xamarin.Mac to read plists, so change to use
our purely managed plist reader in Xamarin.MacDev instead.
That makes us able to change mtouch to be a normal command-line
executable (and project).
Which makes it logical to not mkbundle mtouch anymore,
it executes just fine with the system mono (and there's
no code to protect anymore either).
And since mmp and mtouch share some files, do the same
for mmp.
Chris Hamons
Rolf Bjarne Kvinge
Sebastien Pouliot
Sebastien Pouliot
Manuel de la Pena
Alex Soto
Alex Soto
Vincent Dondain
Timothy Risi