Object::ID object_id is not stable across threads

Inizia da Object::ID's t/threads.t e riproduci i fallimenti su entrambi i backend, JVM e interpreter. Traccia come Hash::FieldHash memorizza l'ID dell'oggetto del thread padre durante l'accesso dal thread figlio, quindi verifica che il test superi su entrambi i backend e che i test esistenti di Hash::FieldHash e dei thread continuino a superare.

Object::ID threaded object identity differs from system Perl

Summary

The CPAN compatibility run for Object::ID v0.1.2 reports 5 failing assertions in t/threads.t. The failure is reproducible on both the JVM backend and the interpreter backend and appears to be a PerlOnJava ithreads/object-identity bug involving the field storage used by Hash::FieldHash.

Evidence

• CPAN run: 20260916-111623-23683
• Distribution: Object-ID v0.1.2
• Test: t/threads.t
• System Perl: the focused upstream test passes, including all 11 object identity assertions.
• PerlOnJava JVM backend: 5 of 11 assertions fail.
• PerlOnJava interpreter backend: 5 of 11 assertions fail.

The failing assertions all have the same shape:

object_id in a thread: got c, expected b

The test creates one object, records its object_id, then checks that the same object has the same ID from five child threads. PerlOnJava assigns a different ID in the child-thread view, while system Perl preserves the identity.

Suspected cause

Object::ID stores IDs in a Hash::FieldHash fieldhash. The parent thread assigns the object ID before starting the threads. When the object is accessed by a child thread, the fieldhash mapping does not appear to be preserved or shared with the cloned object state, so object_id allocates a new ID instead of returning the parent-thread ID.

Because both execution backends reproduce the same result, this is likely in shared thread/object cloning or fieldhash integration rather than in only one compiler backend.

Reverse-dependency impact

MetaCPAN reports 7 released distributions with a runtime dependency on Object::ID; one has a release within the last three years (StorageDisplay). The dependants include StorageDisplay, MooX-Struct, perl5i, Fey-ORM, Role-Commons, Test-Proto, and Module-Install-RDF.

The underlying Hash::FieldHash dependency has 17 released runtime dependants, but none has released within the last three years. This broader count is contextual; the observed defect is specifically threaded use of Object::ID, so the practical affected surface is narrower than the total dependant count.

Suggested acceptance criteria

1. Object::ID t/threads.t passes on the JVM backend.
2. The same test passes on the interpreter backend.
3. The object ID remains stable when the object is accessed from all child threads.
4. Existing Hash::FieldHash and thread tests continue to pass.