I'd like to get a firmer grasp of how frequently the runtime in any language that requires one is being called. In this case, I'm specifically interested in knowing:
Of all the function calls getting executed on an OS X or iOS system in any given second (approximations are of course necessary) how many of those are Objective-C runtime functions (i.e. functions that are defined by the runtime)?
Of course it depends on your application, but in general the answer is "a whole lot". Like, a whole freaking lot.
If you really want to see numbers, I'd recommend using dtrace to log all runtime functions as they're called. This blog entry talks about how to do such a thing.
A lot. Here are just a few examples.
Every time you send a message, the actual message sending is done by a runtime function (this is in fact the most called runtime function in pretty much any objective C program).
NSObject class and protocol are not part of the standard library but part of the runtime, therefore any method that ends up executing to the default NSObject implementation is in fact executing runtime code.
Every time you execute a default property accessor (either read or write), that's part of the runtime.
If you use ARC, every time you access a weak reference (either for reading or writing it) that's a runtime function.
Objc runtime includes the C runtime, so anything that involves a C runtime function (for example passing a large structure by value or returning it) is in fact calling into the runtime.
and more.
Related
Swift is a precompiled language, and all objects are converted to memory addresses; however, there is a special "Selector" in Swift that allows functions to be found by function names at runtime. How did this work? Does this mean that naming functions will affect operational efficiency?
No, function names do not meaningfully affect performance in Swift.
Function and method names are used in two primary ways once compiled into your program:
When a function is called directly (statically) by name, the compiled code refers to the symbol (function name, converted into a format suitable for inclusion in the binary code produced) — which is then converted into a constant jump operation during linking, either statically or dynamically
Simplified: the function name has no effect on calling the function; it is not taken into consideration in any way when making the call
When a function is called dynamically using the Objective-C runtime (e.g., as a selector), the function name is used to look up the appropriate method in a class's method cache. Selectors are unique in a program, so function/method names are mapped to a globally-unique selector, which is then what is used for lookup (by pointer, not by name)
When you refer to a selector statically (e.g. with #selector(...)), the unique selector is pre-compiled in to your program, so the name never needs to be looked up at runtime, and the selector pointer itself can instead be used directly when calling methods
If you refer to a selector dynamically (e.g. NSSelectorFromString(...)), the selector is looked up from the given name dynamically (in a global table of unique selectors), and if not found, a new selector is dynamically created at runtime
In both case (1) and (2a), the name of the function is never really used in the process of making the call, and is irrelevant. In case (2b), it technically is (for selector lookup), but the process is so fast that it really doesn't matter. Method names are rarely long, since they are most often typed by hand, and compared to most operations a program can perform, even the most dynamic use-case (looking up methods manually at runtime) is so insignificant that you really shouldn't worry about it.
One other consideration: when you compile a program with symbols embedded in it, those symbols take up space in your binary. You shouldn't really worry about that either because:
A release build of a program will have most symbols stripped out, and
Compared to the size of a binary due to code, the amount of space symbols take up is usually also totally insignificant
In my C++ library I have a function that is still there, 1) for debugging 2) for small operations.
The function is basically a very slow fallback of more efficient versions.
(think of a loop of individual assigments vs memcpy for example)>
For this reason I would like to emit a warning as soon the function is invoked instantiated directly or indirectly. Without a warning it is not easy to test if the function is being invoked instantiated, because the function might be called instantiated trough several layers of template code.
I found that GCC's __attribute__((warning("slow function!"))) does the job quite well.
template<class T>
__attribute__((warning("careful this fun is very slow, redesign your algorithm")))
void slow_function(T){...}
However it is not standard or compatible with clang.
Is there a better alternative for this kind of compile time warning?
It looks like there is a standard [[deprecated("msg")]] attribute that also does the job, the problem is that it is confusing because there is nothing deprecated about this function, it is there for convenience.
There is also, I found recently a #pragma poison that might be applicable here, but I don't understand how it is used, besides the function is actually a member function of a template class, the examples do not consider this case. https://www.fluentcpp.com/2018/09/04/function-poisoning-in-cpp/
The question came up while I was trying to write a lookup table and during debugging I had the impression, that the array might not be initialized at compile or load time, but rather in a lazy way... Unfortunately I could not find the answer in the MSDN chapter about arrays.
Lets look at some sample code first. The code is in a compiled application, not a script, btw.
module Foo =
let bar = [| for i in 0..9 -> yield (i*i) |]
When does Foo.bar get initialized?
At compile time?
At load time?
Lazy, when first accessed?
Never? (Stays an IEnumerator based sequence despite its array type?)
On a side note, my sequence expression is more complicated than the example above and also uses other functions within scope.
Are there cases which are handled in different ways, such as trivial vs complex eypression or long vs short array etc?
Foo.bar gets initialized at load time - or, when your application starts.
There are slight differences between how this is done for libraries and for applications. For applications, the compiler inserts appropriate initialization into the Main method. For libraries, the initialization check is inserted into static constructors of (I believe) all types, so when you access any type from a library, the initialization is done (this may be sometime after Main, but still before you run any code from the library).
It does not really depend on what the code is - if it is a value, it will be initialized. There are some values like Lazy<T> or IEnumerable<T> that do not immediately fully evaluate, but the value is initialized nevertheless.
Does Swift keep the the method lookup list when compiled or does it call a function in a specific memory location?
Best regards.
Regarding this: http://davedelong.tumblr.com/post/58428190187/an-observation-on-objective-c
I would recommend you have a look at the below links, especially the first one because it explains the concepts with examples from C++ and Objective-C, in order to have a better understanding of the difference between static, late and dynamic dispatch (for methods).
In a nutshell:
Static dispatch
The function and its implementation is determined at compile time and thus can’t fail at runtime (because the compiler will not continue the compilation process unless the binding is successful).
Late dispatch
The function is determined at compile time, but the actual implementation depends on the type of the object at runtime. Important for inheritance. The compiler will check if the the class or any of its parents have the function declared, but its up to the runtime to choose which implementation to use. The late binding can be implemented using virtual tables like in the case of C++.
Dynamic dispatch
The function is determined at runtime, which in the case of Objective-C can be called by name and thus can fail at runtime if the receiver (object) doesn't implement or inherit a method that can respond to a specified message.
References
What is the difference between Dynamic, Static and Late binding?
What is early and late binding?
What is the difference between dynamic dispatch and late binding in C++?
Is it possible to dynamically modify symbol table at runtime in C (in elf format on Linux)?
My eventual goal is the following:
Inside certain function say foo, I want to override malloc function to my custom handler my_malloc. But outside foo, any malloc should still call to malloc as in glibc.
Note: this is different from LD_PRELOAD which would override malloc during the entire program execution.
Is it possible to dynamically modify symbol table at runtime in C (in elf format on Linux)?
In theory this is possible, but in practice it's too hard to do.
Inside certain function say foo, I want to override malloc function to my custom handler my_malloc. But outside foo, any malloc should still call to malloc as in glibc.
Modifying symbol table (even if it were possible) would not get you to your desired goal.
All calls from anywhere inside your ELF binary (let's assume foo is in the main executable), resolve to the same PLT import slot malloc#plt. That slot is resolved to glibc malloc on the first call (from anywhere in your program, assuming you are not using LD_BIND_NOW=1 or similar). After that slot has been resolved, any further modification to the symbol table will have no effect.
You didn't say how much control over foo you have.
If you can recompile it, the problem becomes trivial:
#define malloc my_malloc
int foo() {
// same code as before
}
#undef malloc
If you are handed a precompiled foo.o, you are linking it with my_malloc.o, and you want to redirect all calls from inside foo.o from malloc to my_malloc, that's actually quite simple to do at the object level (i.e. before final link).
All you have to do is go through foo.o relocation records, and change the ones that say "put address of external malloc here" to "put address of external my_malloc here".
If foo.o contains additional functions besides foo, it's quite simple to limit the relocation rewrite to just the relocations inside foo.
Is it possible to dynamically modify symbol table at runtime in C (in elf format on Linux)?
Yes, it is not easy, but the functionality can be packaged into a library, so at the end of the day, it can be made practical.
Typemock Isolator++
(https://www.typemock.com/isolatorpp-product-page/isolate-pp/)
This is free-to-use, but closed source solution. The usage example from documentation should be instructive
TEST_F(IsolatorPPTests, IsExpired_YearIs2018_ReturnTrue) {
Product product;
// Prepare a future time construct
tm* fakeTime = new tm();
fakeTime->tm_year = 2018;
// Fake the localtime method
FAKE_GLOBAL(localtime);
// Replace the returned value when the method is called
// with the fake value.
WHEN_CALLED(localtime(_)).Return(fakeTime);
ASSERT_TRUE(product.IsExpired());
}
Other libraries of this kind
Mimick, from Q: Function mocking in C?
cpp-stub, from Q: Creating stub functionality in C++
Elfspy, for C++, but sometimes it's OK to test C code from C++ unittests, from Q: C++ mock framework capable of mocking non-virtual methods and C functions
HippoMocks, from Q: Mocking C functions in MSVC (Visual Studio)
the subprojects in https://github.com/coolxv/cpp-stub/tree/master/other
... there is still more, feel free to append ...
Alternate approaches
ld's --wrap option and linker scripts, https://gitlab.com/hedayat/powerfake
various approaches described in answers for Q: Advice on Mocking System Calls
and in answers to Q: How to mock library calls?
Rewrite code to make it testable
This is easier in other languages than C, but still doable even in C. Structure code into small functions without side-effects that can be unit-tested without resorting to trickery, and so on. I like this blog Modularity. Details. Pick One. about the tradeoffs this brings. Personally, I guturally dislike the "sea of small functions and tons of dependency injection" style of code, but I realize that that's the easiest to work with, all things considered.
Excursion to other languages
What you are asking for is trivial to do in Python, with the unittest.mock.patch, or possibly by just assigning the mock into the original function directly, and undoing that at the end of the test.
In Java, there is Mockito/PowerMock, which can be used to replace static methods for the duration of a test. Static methods in Java approximately correspond to regular functions in C.
In Go, there is Mockey, which works similarly to what needs to be done in C. It has similar limitations in that inlining can break this kind of runtime mocking. I am not sure if in C you can hit the issue that very short methods are unmockable because there is not enough space to inject the redirection code; I think more likely not, if all calls go through the Procedure Linkage Table.