I think your argumentation is overlooking the fact that Perl code doesn't equal compiled machine code.

What the OS treats as text pages (code) is what is marked as such in the respective binary or shared library that's being loaded.  With respect to Perl, this applies only to the compiled machine code that makes up the interpreter itself, not the "byte code"-like instructions that Perl code is compiled into at runtime (i.e. after the Perl binary has been loaded/mapped).

In other words, from the perspective of the OS, the compiled Perl opcodes are considered "data" (located on the heap) of the Perl executable. And you'd have to have rather good knowledge of the Perl internals to tell whether some bits in those data structures might possibly change (or not) as a result of running the code, which in turn would trigger copy-on-write...

Linux only initially copies the page tables (very small). Solaris, on the other hand, does copy all of the address space (unless you use vfork).

Thanks for the correction. I didn't know that some systems (i.e. Solaris) didn't use copy-on-write.

In both environments, text (ie code) pages are read-only.

And thus they can't possibly be used. Perl wouldn't be able to populate it if it started read-only. Additionally, it can't become read-only (if that's possible) because Perl can compile more code at any time (as mentioned earlier).