Project

General

Profile

Actions

Feature #22232

open

Deprecate `RHASH_TBL` and associated APIs

Feature #22232: Deprecate `RHASH_TBL` and associated APIs

Added by byroot (Jean Boussier) 2 days ago. Updated 2 days ago.

Status:
Open
Assignee:
-
Target version:
-
[ruby-core:126293]

Description

I would like to deprecate RHASH_TBL, RHASH_TBL_RAW and rb_hash_bulk_insert_into_st_table.

Problem

These API take a RHash instance and return its associated st_table *.
If the Hash isn't backed by an st_table it will force convert it.

I think it's a bad API because:

  • It allows to mutate the hash without triggering write barriers (dangerous).
  • Using it on a Hash backed by an ar_table blow memory usage.
  • It restrict evolution of RHash, as we must always be able to convert a Hash into a public st_table.

There are various optimizations that would make sense for RHash but that would break the public ruby/st.h API,
as such, in the future we may want to essentially fork ruby/st.h to have a distinct internal version dedicated to RHash.

Just to give an example, st_table.type is very wasteful for RHash, as it's a full length 8B pointer that has only 2 possible values.
It would be way more efficient to pass it as an argument every time, and get rid of some pointer chasing.

With the possible future introduction of arbitrary length allocation in the GC, we might also want RHash to allocate its bins and entries with the GC rather than malloc.

Both those ideas aren't possible to implement (or much harder) if we need to support RHASH_TBL.

Impact

I need to figure out how to use the gem search server, but a preliminary search on GitHub didn't show a lot of usage, it's a relatively rare API
and if there are use cases that currently necessitate using st_* functions on RHash we should define equivalent rb_hash_ functions to replace them.

Actions

Also available in: PDF Atom