New release tag?

[i-lina]

Hello,

Is there a plan for a new release tag. We are specifically interested in the Windows for Arm64 enablement and would be great to have a release tag with this new feature on mainline.

Thanks.

[davidchisnall]

Good idea. @triplef , is it ready for a release?

The main thing to do is update the release notes.

[triplef]

I think so. To be honest we haven’t been able to test the WOA implementation with our app yet as we still need to figure out some other dependencies, but since all the tests are passing I don’t see anything in the way of doing a release.

[hmelder]

I have tested it and ran the gnustep base test suite (gnustep/tools-windows-msvc#34 (comment)). I think it is ready for a release.

[hmelder]

Thinking about this, we might want to check if libobjc2 compiles on platforms with no block trampoline, and fast-path message send implementation. At least the test suite refuses to compile as objc/message.h is fenced by platform checks.

[hmelder]

@davidchisnall I think we are ready for a new release. I can look into #247, as this seems to work in libs-base but not in an isolated test. What do you think?

[davidchisnall]

I'd like to see if we can get the MinGW EH bits sorted. If the clang changes work, then we can ship with a note that you can't use it unless you're using a trunk build of clang / the next release. It would be a shame to land the support a week after the release.

[hmelder]

A note that fast-path dispatch for aarch64, mips, and riscv64 is only automatically emitted by clang 18.0 >= would be great.

[davidchisnall]

I'd also like to add support for objc_alloc. I think this is fairly simple, we can use the same approach as for ARC, where if NSObject implements +_AllocIsTrivial and the created class does not override it then we just call class_createInstance and otherwise call +alloc. This should give a modest code-size reduction, if nothing else. It's probably worth adding the other objc_opt_* things at the same time (especially objc_opt_new - I always favoured calling +new over +new / -init because of the code-size savings, with objc_opt_new, in the common case we only have one full message send. From what I can see, the Apple runtime only has five of the fast paths there, so adding them isn't too much work.

Ideally I'd like to add direct method support. This mostly requires changes in the compiler (maybe I'll have a pass at this over the weekend), but for it to be efficient we may also want to expose objc_send_initialize as a public symbol (direct class methods need to check for initialisation). I don't really like that approach though, I'd much rather that we did a thing closer to C++ static initialisation and, for classes with direct methods, exposed a guard variable that's set, so we just need a load and conditional branch in the fast path. So the code looks like:

if (__objc_{classname}_init_guard == 0)
{
  objc_send_initialize(self);
}
// body of the direct method

This requires a few changes in the runtime:

• We need to add a pointer to that variable in the class structure.
• We need to set it at the end of objc_send_initialize if it exists.

We can probably do this without changing the size of the Class structure. The extra_data field is unused at startup (it is used the first time a class lock is acquired, so we'd need to be a little bit careful when we read it). Alternatively, metaclasses don't have ivars, so we could add a fake entry on its ivar list. Thoughts welcome.

[davidchisnall]

See #268. I remembered what I could do the guard thing: direct class methods can be called from subclasses and must send initialise to all of the classes in the hierarchy that need it. The new approach should do that and still be fast.

[davidchisnall]

I think everything I wanted is now in, so I can do a new release tomorrow if no one objects (@hmelder, @triplef?).

It would be nice to have the PowerPC trampolines in, but we can always do another release once that's stabilised, especially if it also comes with PowerPC objc_msgSend.

[hmelder]

It would be nice to have the PowerPC trampolines in, but we can always do another release once that's stabilised, especially if it also comes with PowerPC objc_msgSend.

I have written a PowerPC 64-bit objc_msgSend implementation yesterday (See https://github.com/gnustep/libobjc2/tree/powerpc-msgSend), but it is not ready yet. I agree with you that we should first stabilize the port before releasing it.

I think everything I wanted is now in, so I can do a new release tomorrow if no one objects.

No objections. Thank you for doing this!

[triplef]

Sounds good to me, thanks!

I still haven't gotten to work more on WOA for our app or tried out direct method support as we just had a major launch, but with that out of the way I'm planning to start getting back into WOA.

[davidchisnall]

https://github.com/gnustep/libobjc2/releases/tag/v2.2

Thanks everyone!