Philip Withnall e2875a9fca
gthread: Move thread _impl functions to static inlines for speed
The changes made in commit bc59e28bf6b0f70ff345aef80356d0076f44a0e7
(issue #3399) fixed introspection of the GThread API. However, they
introduced a trampoline in every threading function. So with those
changes applied, the disassembly of `g_mutex_lock()` (for example) was:
```
0x7ffff7f038b0 <g_mutex_lock>    jmp 0x7ffff7f2f440 <g_mutex_lock_impl>
0x7ffff7f038b5                   data16 cs nopw 0x0(%rax,%rax,1)
```

i.e. It jumps straight to the `_impl` function, even with an optimised
build. Since `g_mutex_lock()` (and various other GThread functions) are
frequently run hot paths, this additional `jmp` to a function which has
ended up in a different code page is a slowdown which we’d rather avoid.

So, this commit reworks things to define all the `_impl` functions as
`G_ALWAYS_INLINE static inline` (which typically expands to
`__attribute__((__always_inline__)) static inline`), and to move them
into the same compilation unit as `gthread.c` so that they can be
inlined without the need for link-time optimisation to be enabled.

It makes the code a little less readable, but not much worse than what
commit bc59e28bf6b0f70ff345aef80356d0076f44a0e7 already did. And perhaps
the addition of the `inline` decorations to all the `_impl` functions
will make it a bit clearer what their intended purpose is
(platform-specific implementations).

After applying this commit, the disassembly of `g_mutex_lock()`
successfully contains the inlining for me:
```
=> 0x00007ffff7f03d80 <+0>:	xor    %eax,%eax
   0x00007ffff7f03d82 <+2>:	mov    $0x1,%edx
   0x00007ffff7f03d87 <+7>:	lock cmpxchg %edx,(%rdi)
   0x00007ffff7f03d8b <+11>:	jne    0x7ffff7f03d8e <g_mutex_lock+14>
   0x00007ffff7f03d8d <+13>:	ret
   0x00007ffff7f03d8e <+14>:	jmp    0x7ffff7f03610 <g_mutex_lock_slowpath>
```

I considered making a similar change to the other APIs touched in #3399
(GContentType, GAppInfo, GSpawn), but they are all much less performance
critical, so it’s probably not worth making their code more complex for
that sake.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

Fixes: #3417
2024-08-26 08:38:58 +01:00
..
2023-11-28 13:52:05 +00:00
2023-11-02 16:30:23 +00:00
2023-11-02 16:30:23 +00:00
2024-04-01 11:01:06 +00:00
2022-05-23 09:19:45 -04:00
2023-10-11 17:38:31 +01:00
2023-11-15 11:09:39 +00:00
2023-11-15 11:09:39 +00:00
2023-11-15 11:09:39 +00:00
2024-04-01 11:01:06 +00:00
2023-10-23 10:25:31 +01:00
2023-02-09 13:36:51 +00:00
2018-01-04 22:19:30 +01:00
2024-04-01 11:01:06 +00:00
2024-08-01 18:38:57 +02:00
2022-07-25 22:30:22 +01:00
2021-09-21 09:41:29 +00:00
2021-11-18 14:32:09 +00:00
2023-10-11 17:38:31 +01:00
2023-10-11 17:38:31 +01:00
2024-07-09 20:16:20 +01:00
2023-11-28 13:52:05 +00:00
2023-10-11 17:38:30 +01:00
2023-10-11 17:38:31 +01:00
2023-11-28 13:52:05 +00:00
2023-10-23 10:25:31 +01:00
2024-01-17 08:57:12 -05:00
2023-10-23 10:25:31 +01:00
2023-10-11 17:38:31 +01:00
2023-11-28 13:52:05 +00:00
2023-10-17 22:59:27 +01:00
2023-10-17 22:59:27 +01:00
2024-04-01 11:01:06 +00:00
2023-11-28 13:52:05 +00:00
2024-01-19 11:53:00 +00:00
2023-11-28 13:52:05 +00:00
2024-04-01 11:01:06 +00:00
2024-04-01 11:01:06 +00:00
2023-08-01 15:33:21 -03:00