Bug #18779: `GC.compact` and other compaction related methods should be defined as rb_f_notimplement on non supported platforms.

• Status: Closed
• Assignee: -
• Target version: -
• Backport: 2.7: WONTFIX, 3.0: REQUIRED, 3.1: REQUIRED

[byroot (Jean Boussier)]

I received several bug report on native gems using GC.verify_compaction_references in their test suite.

Examples:

• https://github.com/msgpack/msgpack-ruby/pull/275/files
• https://github.com/Shopify/bootsnap/pull/414/files

I think that when !GC_COMPACTION_SUPPORTED, rather than raise NotImplementedError, we should instead define these methods as rb_f_notimplement like Process.fork on Windows.

This way GC.respond_to?(:compact) would be a proper way to test for compaction support.

Unfortunately, these methods are defined through .rb files with Primitive, and I don't know wether it's possible to check GC_COMPACTION_SUPPORTED from there, nor if it's possible to define a rb_f_notimplement method.

cc @tenderlovemaking (Aaron Patterson)

[mdalessio (Mike Dalessio)]

After working through this in https://github.com/sparklemotion/nokogiri/pull/2532#issuecomment-1121302762 I agree that Ruby should provide an easier mechanism for discovering whether compaction is supported.

[mdalessio (Mike Dalessio)]

I've submitted a pull request that addresses this behavior in the way @byroot (Jean Boussier) described above:

https://github.com/ruby/ruby/pull/5934

[byroot (Jean Boussier)]

• Status changed from Open to Closed
• Backport changed from 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN to 2.7: WONTFIX, 3.0: REQUIRED, 3.1: REQUIRED

The PR was merged so we can now close this.

I'm marking 3.0 and 3.1 for backport. The two commits are:

• 0de1495f358e9b892dfa63d4b74f59b1d2903703
• 0c36ba53192c5a0d245c9b626e4346a32d7d144e

[Eregon (Benoit Daloze)]

• Is duplicate of Bug #18560: "Compaction isn't available on this platform" error running PG test suite on ppc64le added

[jaruga (Jun Aruga)]

I'm marking 3.0 and 3.1 for backport. The two commits are:

6ddec1082d06431111123c03b18ca41e7a2cec12
e9623f7432b4603735c74b6f0bb683a9bf19c2c6

Did you backport to ruby_3_0 and ruby_3_1 branches? I cannot find the 2 commit hashes above.

[byroot (Jean Boussier)]

@jaruga (Jun Aruga) no, I requested it, but it's the release manager of each branch that is supposed to do the backport.

These two commits are on master. The backported commits will likely be widely different as there was many changes in compaction APIs between 3.0 and master.

[jaruga (Jun Aruga)]

no, I requested it, but it's the release manager of each branch that is supposed to do the backport.

Sorry for my mistake. The "3.0: REQUIRED, 3.1: REQUIRED" (not DONE) shows the statuses clearly.

These two commits are on master. The backported commits will likely be widely different as there was many changes in compaction APIs between 3.0 and master.

I see. How about changes between 3.1 and master? Many changes? I want to see the backport at least on Ruby 3.1.

Ah I found the 2 commits you shared on the PR below. But the commits were rebased on the master. That's why I could not find those on the master.
https://github.com/ruby/ruby/pull/5934/commits

I think the 2 commits on the master are below.
https://github.com/ruby/ruby/commit/0de1495f358e9b892dfa63d4b74f59b1d2903703
https://github.com/ruby/ruby/commit/0c36ba53192c5a0d245c9b626e4346a32d7d144e

[byroot (Jean Boussier)]

Indeed, thank you.

[vo.x (Vit Ondruch)]

If it helps, this 1 is the patch we are carrying around in Fedora for Ruby 3.1. I would appreciate if is backported, because it influences files which are pregenerated and part of the release tarball 2.

[nagachika (Tomoyuki Chikanaga)]

MEMO: It seems that #18829 is required to be backported preceded for this issue.