No longer installs headers by default. This is because GNUstep Make notices when the objc headers have changed (because GNUstep includes them) and so reinstalling libobjc2 was requiring a complete recompile of anything that you tried to build, even if you only changed one line. A better fix for this would be for install to use cmp or diff to check if the header has been modified before installing it, but I'm too lazy to do that right now.
Fixed the definition of objc_msgSendSuper().
Tweaked the -dealloc implementation for hidden classes used for locking so that @synchronize(self) will work in a -dealloc method.
Removed GNU dtable and sparse array implementations, replaced entirely now with versions based on the Étoilé runtime. Performance is roughly equivalent in microbenchmarks, memory usage is significantly lower (Gorm goes from 95MB to 50MB on my machine - this will be even more pronounced on 64-bit systems), which should improve cache usage considerably. Still room for some performance tuning, however.
I now have an out-of-tree replacement for the dtable stuff, so sarray.{h,c} will be going away soon. The replacement offers similar (slightly worse currently) performance in microbenchmarks, but uses half as much memory (Gorm goes from 95MB to 48MB on my machine). This will be committed once it's been tweaked a little bit.
Imported selector table code frm the Étoilé runtime. We can now make dispatch type dependent with a -D switch. Not enabled yet, but it will be enabled in a warning mode soon - I consider preferable to the existing GNU and Apple solution of corrupting the stack.
The aim of this pass is to identify message send sites which can benefit from speculative inlining and inline caching. By itself, this pass is useless. It will later be combined with one that parses this information and then uses the existing caching and inlining infrastructure to optimize hot message send sites.
Now, however, it's time for me to go and dance, so the useful bit will have to wait.
Microbenchmark that just sends a message that does nothing 1000000000 times in a loop goes from taking 10.2 seconds to taking 4.7 after running the pass.
It would be cleaner to use a ptrdiff_t here, but unfortunately we can't because the ivar_offset field in the runtime metadata is an int so ivar offsets beyond 4GB will not work on LP64 platforms.
This probably isn't a limitation. If you have more than 4GB of ivars in one object, you've done something badly wrong and probably shouldn't be allowed to write code anymore.