gslice: Remove slice allocator and use malloc() instead

Keep the API for ABI compatibility.

See
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2935#note_1650099
for a summary of the reasoning for this change:
 - The performance of system-provided allocators has improved since
   GSlice was written, and they are now similarly as performant, or more
   performant, than GSlice.
 - The code is unmaintained and nobody understands it.
 - It doesn’t integrate with tooling and system security features which
   have been written for the system `malloc()` implementation (such as
   sanitisers, valgrind, etc.).
 - It’s confusing for developers: should they use `g_slice_new()` or
   `g_new()`?
 - GSlice is faster than the libc allocator for allocating and
   (particularly) freeing linked lists, but since these are a rubbish
   data structure, that’s not a great thing to optimise for.

For the cases where application performance is negatively impacted by
the implementation of GSlice being dropped (and we don’t think there’ll
be many), applications can use a drop-in `malloc()` replacement which is
more suited to their particular workload. Choosing an allocator in GLib
to suit all application workloads is not possible.

Including documentation updates and cleanups by Philip Withnall.

Fixes: #1079

NEWS

@@ -1,3 +1,10 @@
+Overview of changes in GLib 2.75.3, UNRELEASED
+==============================================
+
+* Drop the implementation of GSlice, and make the API use the system `malloc()`
+  internally (#1079) (based on investigation work by multiple people)
+
+
 Overview of changes in GLib 2.75.2, 2023-01-06
 ==============================================
 

docs/reference/glib/running.xml

@@ -165,53 +165,10 @@ How to run and debug your GLib application
   <title><envar>G_SLICE</envar></title>
 
   <para>
-    This environment variable allows reconfiguration of the GSlice
-    memory allocator.
-    <variablelist>
-      <varlistentry>
-        <term>always-malloc</term>
-        <listitem><para>This will cause all slices allocated through
-          g_slice_alloc() and released by g_slice_free1() to be actually
-          allocated via direct calls to g_malloc() and g_free().
-          This is most useful for memory checkers and similar programs that
-          use Boehm GC alike algorithms to produce more accurate results.
-          It can also be in conjunction with debugging features of the system's
-          malloc() implementation such as glibc's MALLOC_CHECK_=2 to debug
-          erroneous slice allocation code, although
-          <literal>debug-blocks</literal> is usually a better suited debugging
-          tool.</para>
-        </listitem>
-      </varlistentry>
-      <varlistentry>
-        <term>debug-blocks</term>
-        <listitem><para>Using this option (present since GLib 2.13) engages
-          extra code which performs sanity checks on the released memory
-          slices. Invalid slice addresses or slice sizes will be reported and
-          lead to a program halt. This option is for debugging scenarios.
-          In particular, client packages sporting their own test suite should
-          <emphasis>always enable this option when running tests</emphasis>.
-          Global slice validation is ensured by storing size and address
-          information for each allocated chunk, and maintaining a global
-          hash table of that data. That way, multi-thread scalability is
-          given up, and memory consumption is increased. However, the
-          resulting code usually performs acceptably well, possibly better
-          than with comparable memory checking carried out using external
-          tools.</para>
-          <para>An example of a memory corruption scenario that cannot be
-          reproduced with <literal>G_SLICE=always-malloc</literal>, but will
-          be caught by <literal>G_SLICE=debug-blocks</literal> is as follows:
-          <programlisting>
-            /* void* gives up type-safety */
-            void *slist = g_slist_alloc ();
-
-            /* corruption: sizeof (GSList) != sizeof (GList) */
-            g_list_free (slist);
-          </programlisting></para>
-        </listitem>
-      </varlistentry>
-    </variablelist>
-    The special value <literal>all</literal> can be used to turn on all options.
-    The special value <literal>help</literal> can be used to print all available options.
+    This environment variable allowed reconfiguration of the GSlice
+    memory allocator. Since GLib 2.76, GSlice uses the system
+    <literal>malloc()</literal> implementation internally, so this variable is
+    ignored.
   </para>
 </formalpara>