This uses the type_id registered in the previous commit to avoid many
calls to g_dbus_message_get_type() for type checking within the source
file. We can rely on the type being registered once an object is created
and if not, there is no way the type check could succeed anyway.
This makes the G_DEFINE_TYPE(), G_DEFINE_INTERFACE() and similar variants
provide a TypeName##_type_id global simimlar to how the private offset is
stored as a global.
What this allows for, is for applications and libraries which have high
demand on the type system to have an escape hatch to improve performance.
It has been observed that most of the type checking comes from inside the
same module that implements the type. Therefore, if that source file can
access the GType without an external call to the get_type() function, the
overhead can be reduced to an address load.
For example, this is used in libdex heavily to ensure that get_type() do
not show up in performance profiles. This is done by redefining the type
macro to use the global variable.
#undef FOO_TYPE_BAR
#define FOO_TYPE_BAR FooBar_type_id
The one place where you need to be careful of this is the new function
which may cause the registration of the type if global registration at
library/application startup is not performed.
Additionally, if using new-style G_DECLARE_* macros, you may also want to
override the IS_TYPE() macro to use the fast path.
#define FOO_IS_BAR(obj) G_TYPE_CHECK_INSTANCE_TYPE(obj, FOO_TYPE_BAR)
On this system, this can have a wild performance implication. For example,
the type check for GDBusMessage when dragging a window around in GNOME
Shell and activating the overview had a whopping 2.96% of samples.
When the child process is going to exit on error after fork() but before
exec(), let's close the child_err_report_fd. The practical value of this
is to placate valgrind --track-fds=yes.
The new merge request link only works when logged in to a GitLab
account, unfortunately. Make that clear in the readme.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3460
When we invoke a shell script directly, the system selects a bash binary
that might be different from the one detected by find_program('bash').
Explicitly use the one detected by Meson, matching the behavior of our
other test() invocations on shell scripts.
Fixes test failure on Windows in GitHub Actions CI:
stdout: 1: UNKNOWN: Windows Subsystem for Linux has no installed distributions.
stdout: 2: UNKNOWN: Distributions can be installed by visiting the Microsoft Store:
stdout: 3: UNKNOWN: https://aka.ms/wslstore
Found-by: Benoit Pierre <benoit.pierre@gmail.com>
Fixes: d7601f7eed ("Incorporate some lint checks into `meson test`")
The test in `unix-mounts` to see whether `g_unix_mounts_get_from_file()`
can parse an example file was working fine when GLib is built with
libmount, but not when built without it (and hence typically using
`getmntent()`).
This is because libmount supports mountinfo files (like
`/proc/self/mountinfo`), but `getmntent()` only supports mount files
(like `/proc/mounts`). The test was written only with the former.
So, change the test to use mount files when GLib is built without
libmount support.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3456
The build instructions for msys2 builds are stored outwith
`.gitlab-ci.yml`.
We need to build a specific (recent) version of gobject-introspection so
we can get support for async annotations in `g-ir-scanner`. See !3746.
Fixes commit 93271385f9cb83cdbdf9f850842d3ddae518ed8d.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It’s unclear why there was a hole in this. Let’s keep things less
confusing by eliminating it.
Fixes commit 453dd4be9e906078a7fb7466819ce1876a629a45.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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
As per https://gitlab.gnome.org/GNOME/glib/-/issues/3421#note_2206315:
It seems like there’s agreement that glib_debug should be enabled for
developers and disabled for distros; and it also seems like there’s no
reliable way to figure this out magically (because not everyone ties
things to `-Dbuildtype=*`). So, we’re left with forcing some group of
people to manually set the value of `glib_debug`. There are more
developers/contributors than there are distros, and distros are more
likely to notice an accidentally-slow GLib package than developers are
likely to notice an accidentally-not-asserting-hard-enough local build,
so let’s say:
The default should be `-Dglib_debug=enabled`, and distros should probably
all override that to `-Dglib_debug=disabled`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3421
