GLib merge requestshttps://gitlab.gnome.org/GNOME/glib/-/merge_requests2024-03-18T18:12:43Zhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/3954[th/performance] add script for combining performance results2024-03-18T18:12:43ZThomas Haller[th/performance] add script for combining performance results`gobject/tests/performance/performance.c` is very useful.
1) do a few patches, trying to improve it. In particular,
- tests/performance: ensure to always warm up for 2 seconds
- tests/performance: add "factor" argument to performanc...`gobject/tests/performance/performance.c` is very useful.
1) do a few patches, trying to improve it. In particular,
- tests/performance: ensure to always warm up for 2 seconds
- tests/performance: add "factor" argument to performance test
- tests/performance: print result in unique line
2) add a `gobject/tests/performance/performance-run.sh` for running and combining the results. This is extremely hacky and ugly. It's also not great. However, I think it's still rather useful. The alternative of trying to do these steps manually is error prone and cumbersome.2.80.1https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3959[th/gobject-toggle-refs-check] Fix critical warning for toggle notifications ...2024-03-18T14:21:30ZThomas Haller[th/gobject-toggle-refs-check] Fix critical warning for toggle notifications in g_object_ref()/g_object_unref()- there is some duplicated code in `g_object_ref()`/`g_object_unref()`, move it to a new function `toggle_refs_check_and_ref()`.
- fix assertion `"Unexpected number of toggle-refs. g_object_add_toggle_ref() must be paired with g_object_...- there is some duplicated code in `g_object_ref()`/`g_object_unref()`, move it to a new function `toggle_refs_check_and_ref()`.
- fix assertion `"Unexpected number of toggle-refs. g_object_add_toggle_ref() must be paired with g_object_remove_toggle_ref()"`
- add more code comments about why the code is correct.2.80.1https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3834[th/weak-ref-lock-2] gobject: use per-object bit-lock instead of global RWLoc...2024-03-12T09:44:55ZThomas Haller[th/weak-ref-lock-2] gobject: use per-object bit-lock instead of global RWLock for GWeakRefThis replaces !3832.
Updated: 20240224
The second commit "gobject: avoid global GRWLock for weak locations in g_object_unref() in some cases" now avoids taking the global GRWLock for most code paths. Arguably, that already fixes most o...This replaces !3832.
Updated: 20240224
The second commit "gobject: avoid global GRWLock for weak locations in g_object_unref() in some cases" now avoids taking the global GRWLock for most code paths. Arguably, that already fixes most of the performance concerns about the global lock.
The 3 commit "gobject: use per-object bit-lock instead of global RWLock for GWeakRef" then actually replaces the global lock with a per-object lock. I still think its worth it to do...
Closes #743https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3932ci: Use Meson version from pacman on msys2 CI runners2024-02-15T21:56:12ZPhilip Withnallci: Use Meson version from pacman on msys2 CI runnersRather than pinning it to the lowest version we support, as is the
standard policy.
This means we’ll end up using version 1.3.2-2, which has just been
packaged to contain the fix for
https://github.com/mesonbuild/meson/issues/12330, whi...Rather than pinning it to the lowest version we support, as is the
standard policy.
This means we’ll end up using version 1.3.2-2, which has just been
packaged to contain the fix for
https://github.com/mesonbuild/meson/issues/12330, which has been
impacting GLib significantly since we started installing
gobject-introspection in CI in commit
c428d6e67318e7b02c13111db260ed98622e982a.
Thanks to Christoph Reiter, Luca Bacci and Simon McVittie for diagnosing
and fixing this issue.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3262
Closes #32622.79.3Philip WithnallPhilip Withnallhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/3919tests: Speed up threaded toggle notify test unless -m slow is passed2024-02-13T09:46:16ZPhilip Withnalltests: Speed up threaded toggle notify test unless -m slow is passedOn a fast laptop, this test currently takes about 7s to run, which is a
significant portion of the overall test suite time.
On a slower CI machine, especially running the test under valgrind, the
test can time out.
There’s no need to a...On a fast laptop, this test currently takes about 7s to run, which is a
significant portion of the overall test suite time.
On a slower CI machine, especially running the test under valgrind, the
test can time out.
There’s no need to always run so many iterations: we run the tests under
CI so often that it’s likely a failure will eventually be hit (if there
is a bug) even with fewer iterations. We also now run the tests once a
week with `-m slow`, so the original iteration count will also still be
used then.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>Philip WithnallPhilip Withnallhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/2889Run tests with G_ENABLE_DIAGNOSTIC=12024-02-10T19:30:28ZSimon McVittieRun tests with G_ENABLE_DIAGNOSTIC=1* !2912 (prerequisite for this)
* tests: Move common test environment variables to top level
* gio/tests: Disable deprecation warnings where necessary
The defaultvalue test sets all properties, even the deprecated ones.
* gob...* !2912 (prerequisite for this)
* tests: Move common test environment variables to top level
* gio/tests: Disable deprecation warnings where necessary
The defaultvalue test sets all properties, even the deprecated ones.
* gobject/tests: Exercise a floating object reaching last-unref
This was previously exercised (probably by mistake) in
gobject/tests/type.c, but without making any assertions about what
happened, and the test would fail under G_ENABLE_DIAGNOSTIC if GLib was
compiled with debug enabled.
* gobject/tests: Don't unref a floating object reference by mistake
This goes undiagnosed under normal circumstances, but is a critical
warning (which is fatal by default) under G_ENABLE_DIAGNOSTIC. This is a
programming error, so we should only exercise it under
g_test_undefined(), and only in a test that is intentionally doing this
(as in the previous commit).
* tests: Run all tests with deprecated property warnings enabled
The tests that functionally rely on G_ENABLE_DIAGNOSTIC=1 still set it
explicitly, so that they will behave as expected when run as
installed-tests or manually.2.75.0Simon McVittieSimon McVittiehttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/3887gtestutils: Ensure test_data is freed even if a test is skipped2024-02-06T18:33:25ZPhilip Withnallgtestutils: Ensure test_data is freed even if a test is skippedIt’s reasonable for the `main()` function in a test suite to pass
ownership of some test data to `g_test_add_data_func_full()`, along with
a `GDestroyNotify`, and rely on GTest to free the data after all tests
have been run.
Unfortunate...It’s reasonable for the `main()` function in a test suite to pass
ownership of some test data to `g_test_add_data_func_full()`, along with
a `GDestroyNotify`, and rely on GTest to free the data after all tests
have been run.
Unfortunately that only worked if the test was run, and not skipped
before its test function was called. This could happen if, for example,
it had `/subprocess` in its path.
Fix that by always freeing the test data. This required reworking how
tests are skipped, slightly, to bring all the logic for that within
`test_case_run()`, so that it could always handle the memory management.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3248Philip WithnallPhilip Withnallhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/3879[th/gdataset-comment] gdataset: add code comment to g_datalist_get_data()2024-02-05T16:52:01ZThomas Haller[th/gdataset-comment] gdataset: add code comment to g_datalist_get_data()TRIVIAL
---
It's not obvious why we wouldn't use `g_quark_try_string()`. Add a code
comment that this is intentional and a reference for how to find out
more.
Also, fix typo in another code comment.TRIVIAL
---
It's not obvious why we wouldn't use `g_quark_try_string()`. Add a code
comment that this is intentional and a reference for how to find out
more.
Also, fix typo in another code comment.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3838build: Add thorough test setup2024-02-02T14:46:33ZPhilip Withnallbuild: Add thorough test setupThis allows the tests to be run with `meson test --setup thorough` and
it will run all the GTest tests with `-m thorough`.
Since this argument isn’t supported by the Python tests, it’s not passed
to them.
The tests are then added to th...This allows the tests to be run with `meson test --setup thorough` and
it will run all the GTest tests with `-m thorough`.
Since this argument isn’t supported by the Python tests, it’s not passed
to them.
The tests are then added to the weekly schedule to run thoroughly.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>Philip WithnallPhilip Withnallhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/3869[th/optimize-weak-ref-list] rework GObject's `WeakRefData` to track reference...2024-02-02T14:01:11ZThomas Haller[th/optimize-weak-ref-list] rework GObject's `WeakRefData` to track references in an array instead of GSListI think it's worth optimizing the core of GObject, for efficiency and memory consumption.
Using a `GSList` is quite convenient (in particular in terms of writing concise code), but not as efficient as could be.
Replace it by a list of ...I think it's worth optimizing the core of GObject, for efficiency and memory consumption.
Using a `GSList` is quite convenient (in particular in terms of writing concise code), but not as efficient as could be.
Replace it by a list of pointers. And the first weak ref is interned/embedded in `WeakRefData` itself.
I did some (naive) measurements, and it's measurably faster. However, to be fair, it's only faster by a few percent(*). What is also interesting, is that it requires less heap allocations.
(*) the unrealistic `/object/weak-ref/many` unit tests (with `-m slow`) gets 80% faster.
For example
- with `len==1` it requires no additional allocation and saves one GSList.
- with `len>1` we allocate a buffer, by doubling the array. For example, with 2 elements, we allocate an array of 4. This is the worst case, where we allocate 4 pointers to track two element. Note that 2 GSList also require 2 x 2 pointers (albeit two separate heap allocations, which may or may not have additional overhead).
~The buffer doesn't shrink, until it reaches a length of 1. In that sense, the GSList approach is better to shrink the memory. Not shrinking is an intentional choice, in the hope that we might still reuse the memory later. If we think it would be better, we could easily shrink the buffer (to not do worse than GSList in this regard).~ The buffer now also shrinks (when 75% empty to 50%). That means, in the worst case we waste 75% of the array (while with GSList we always require +50% for the next pointer).https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3866[th/gobject-carray-comment] gobject: remove obsolete code comment about CArray2024-01-31T14:09:06ZThomas Haller[th/gobject-carray-comment] gobject: remove obsolete code comment about CArrayIt's not clear what this code comment tries to tell us. Yes, when we
make changes, we must take care that the changes are correct and update
the relevant places.
It seems long obsolete. Drop it.
This partly reverts commit d7dd9aefd840 ...It's not clear what this code comment tries to tell us. Yes, when we
make changes, we must take care that the changes are correct and update
the relevant places.
It seems long obsolete. Drop it.
This partly reverts commit d7dd9aefd840 ('placed a comment about not
changing CArray until we have').https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3865[th/test-weak-notify] gobject/tests: add test checking that GWeakRef is clear...2024-01-31T12:35:53ZThomas Haller[th/test-weak-notify] gobject/tests: add test checking that GWeakRef is cleared in GWeakNotifyg_object_weak_ref() refers to GWeakRef as thread safe replacement.
However, it's not clear to me, how GWeakRef is a replacement for
a callback. I think, it means, that you combine g_object_weak_ref()
with GWeakRef, to both hold a thread-...g_object_weak_ref() refers to GWeakRef as thread safe replacement.
However, it's not clear to me, how GWeakRef is a replacement for
a callback. I think, it means, that you combine g_object_weak_ref()
with GWeakRef, to both hold a thread-safe weak reference and get a
notification on destruction.
Add a test, that GWeakRef is already cleared inside the GWeakNotify
callback.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3774[th/g-object-priv] add private data to GObject and use per-object locking2024-01-31T08:56:50ZThomas Haller[th/g-object-priv] add private data to GObject and use per-object locking- add a GObjectPrivate data (via `g_type_add_instance_private()`).
- use it for the "optional_flags" on archs that don't have `HAVE_OPTIONAL_FLAGS`.
- convert mutexes to bitlocks in private data.
~~The first problem is, it doesn't ac...- add a GObjectPrivate data (via `g_type_add_instance_private()`).
- use it for the "optional_flags" on archs that don't have `HAVE_OPTIONAL_FLAGS`.
- convert mutexes to bitlocks in private data.
~~The first problem is, it doesn't actually work. Tests don't pass. Unclear why. TODO.~~ (FIXED)
~~The second problem is, `g_bit_lock()` seems only to support one bit per integer ([doc](https://gitlab.gnome.org/GNOME/glib/-/blob/35c21681c1c661a0b9bc9d27e640e41b4088482e/glib/gbitlock.c#L192)). Maybe that limitation could be fixed, but as it is, each mutex requires one `gint` per GObject. Which is too bad, since we have plenty of unused bits in `optional_flags`.~~ (FIXED: we can reuse the `gint`, as long as we are careful not to toggle any flags while holding a bitlock. In particular, we must not take a lock while holding another lock (of these kinds) and cannot change `option_flags` while holding a bitlock).
WDYT?2.79.2https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3769[th/g-object-unref-ref] fix race in g_object_unref()2024-01-30T14:34:22ZThomas Haller[th/g-object-unref-ref] fix race in g_object_unref()Fix for
- https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3762#note_1946898
- https://gitlab.gnome.org/GNOME/glib/-/issues/3064
- https://gitlab.gnome.org/GNOME/glib/-/issues/2384
@mcatanzaro, @pwithnall
Closes #3064, #2384Fix for
- https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3762#note_1946898
- https://gitlab.gnome.org/GNOME/glib/-/issues/3064
- https://gitlab.gnome.org/GNOME/glib/-/issues/2384
@mcatanzaro, @pwithnall
Closes #3064, #23842.79.2https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3813gobject: define HAVE_OPTIONAL_FLAGS for sizeof(void*) > 82024-01-16T09:02:24ZAlexander Richardsongobject: define HAVE_OPTIONAL_FLAGS for sizeof(void*) > 8The padding space for this extra field is also available if `void *` is
larger than 8 bytes.The padding space for this extra field is also available if `void *` is
larger than 8 bytes.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3826genums: use g_once_init_enter_pointer for GType initializers2024-01-16T09:00:58ZAlexander Richardsongenums: use g_once_init_enter_pointer for GType initializersGType is either an integer or a pointer, so we have to use the _pointer
version here to support architectures such as Morello.
These two lines were missed in 5ecd3cbe525debf78e38955280f3eb5804080732
and allows the gobject/enums test to ...GType is either an integer or a pointer, so we have to use the _pointer
version here to support architectures such as Morello.
These two lines were missed in 5ecd3cbe525debf78e38955280f3eb5804080732
and allows the gobject/enums test to pass on CheriBSD (Morello).
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3799tests: Fix a minor leak in the new GParamSpecPool test2024-01-03T12:47:47ZPhilip Withnalltests: Fix a minor leak in the new GParamSpecPool testSigned-off-by: Philip Withnall <pwithnall@gnome.org>Signed-off-by: Philip Withnall <pwithnall@gnome.org>Philip WithnallPhilip Withnallhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/3762[th/notify-queue] some optimization around g_object_freeze_notify()/g_object_...2023-12-21T13:30:43ZThomas Haller[th/notify-queue] some optimization around g_object_freeze_notify()/g_object_thaw_notify()- taking object references when unnecessary (in `g_object_freeze_notify()`, `g_object_thaw_notify()`).
- in g_object_thaw_notify(), avoid the freeze+thaw+thaw.
- in `g_object_notify_by_spec_internal()` path, take less `notify_lock` locks.- taking object references when unnecessary (in `g_object_freeze_notify()`, `g_object_thaw_notify()`).
- in g_object_thaw_notify(), avoid the freeze+thaw+thaw.
- in `g_object_notify_by_spec_internal()` path, take less `notify_lock` locks.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3763girepository: Drop libgio dependency from gdump.c2023-12-20T00:43:01ZEmmanuele Bassigirepository: Drop libgio dependency from gdump.cIt’s not particularly necessary, and makes the build-time dependencies
more complex than they need to be, as it means that to generate
GLib-2.0.gir and GObject-2.0.gir, libgio.so (and its generated headers)
already needs to have been bui...It’s not particularly necessary, and makes the build-time dependencies
more complex than they need to be, as it means that to generate
GLib-2.0.gir and GObject-2.0.gir, libgio.so (and its generated headers)
already needs to have been built.
See discussion on #3164
These changes need to be replicated in gobject-introspection.git before
the problem can be solved, though, as that still has its own copy of
`gdump.c` (which it installs and uses).
Further changes are included to fix pspec pool initialisation during dumping.
Helps: #3164
---
This MR is based on top of !3760, which needs to be merged first.2.79.0Emmanuele BassiEmmanuele Bassihttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/3739Documentation only: Added clarification about GWeakNotify and removed ambiguo...2023-12-04T14:04:10ZmadmurphyDocumentation only: Added clarification about GWeakNotify and removed ambiguous textThe text corrected by this commit led me to ask [a question on GNOME Discourse](https://discourse.gnome.org/t/should-i-call-g-object-weak-unref-during-dispose/18237). I corrected it with words from @ebassi from the same discussion.
By d...The text corrected by this commit led me to ask [a question on GNOME Discourse](https://discourse.gnome.org/t/should-i-call-g-object-weak-unref-during-dispose/18237). I corrected it with words from @ebassi from the same discussion.
By digging deeper, I discovered that the same text might have looked ambiguous for [others](https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3785#note_1044802) too in the past.