OCaml -safe-string string literal sharing across separate modules

Question

With -safe-string enabled by default since OCaml 4.06, strings are immutable and mutation lives in Bytes. The compiler may physically share identical literals inside a single compilation unit, but the language definition does not state whether the same literal in different modules maps to one heap object.

The objective is to establish whether == on string literals is a dependable cross-module identity check. The missing constraint is that separate compilation, inlining, and link order can change literal layout, so behavior may differ between a single executable and a dynamically loaded library.

Does the OCaml separate compilation model guarantee physical identity for identical string literals across modules? Which compilation flags or linking strategies influence whether literals are shared? Is an explicit interning table the only portable way to implement string identity?

Tasadduq Burney · Answer

Short answer
No. OCaml separate compilation does not guarantee that identical string literals in different modules are the same heap object. With -safe-string enabled by default since OCaml 4.06, strings are immutable, but immutability is not the same as sharing. Comparing literals with == across module boundaries is therefore not a dependable identity check.
Confirmed facts

-safe-string controls immutability and moves mutation to Bytes; it does not control whether literals are shared.
Physical sharing of identical literals inside one compilation unit is an implementation optimization, not a language guarantee.
Each compiled unit typically carries its own literal table, and the bytecode or native linker does not deduplicate string constants across compilation units.
Inlining, optimization flags, and dynamic loading through Dynlink can change layout, but none provides a supported cross-module identity guarantee.

Likely explanation
Separate compilation compiles each module independently. The compiler may emit the same literal once per object file, and the linker concatenates those tables without merging duplicate entries. A dynamically loaded library may keep its own copy of constants, so textually identical strings can be different heap objects.
Steps for this case

Do not use == on string literals for identity logic across modules.
Use an explicit interning table, such as Hashtbl or Weak.Hashtbl mapping string to string, and canonicalize values through it before comparing.
To verify your build, compile two modules containing the same literal, link them into one executable, and print the == result. A false result shows no sharing in that configuration.
Repeat the check with Dynlink if you load plugins, because static executables and dynamic libraries can lay out literals differently.

Assumptions and uncertainty
This assumes OCaml 4.06 or later. Literal-table emission can vary between bytecode and native code, linker versions, and loading strategies. No OCaml flag is documented to force cross-module literal deduplication, so do not rely on link order or -O flags as a substitute for interning.
Verification commands
ocamlc -c m1.ml
ocamlc -c m2.ml
ocamlc -o test m1.cmo m2.cmo
./test

Let m1.ml and m2.ml each bind let s = "shared", then compare the two values with ==.

OCaml -safe-string string literal sharing across separate modules

OCaml -safe-string string literal sharing across separate modules

1 answer

Short answer

Confirmed facts

Likely explanation

Steps for this case

Assumptions and uncertainty

Verification commands

Your perspective belongs here.

1 question comment