When a thread is created, the whole active interpreter at that point is cloned (copied) into the new thread. When a thread ends, whatever SVs it returns (either explicitly via return, or implicitly as the last statement, or for XS, whatever SVs it pushes into the stack) are cloned back into the parent thread, by the parent calling the join() method. If the return SVs are non-trivial (e.g. have been blessed into a package), then additional stuff needs to be cloned back. For example if the object is in class X and the 'X' package doesn't exist in the parent (say 'use X' was done in the child, not the parent), then the X package and all the methods in that namespace need copying back too.

What you are seeing is probably a situation where a large 'reverse clone' is being triggered by one of the SVs being returned to the parent. One possibility related to objects is the SVphv_CLONEABLE flag, which if set on the stash the object has been blessed into, triggers reverse-cloning the stash of that object.

One possible side effect of turning off SvOBJECT() on the object is that it causes the SVphv_CLONEABLE test to be skipped (that test is only done on objects) which somehow causes the the stash associated with the (now unblessed) object to be cloned.

But that's just wild speculation at the moment.

Dave.