I now understand the behavior.  A multithreaded system that repeatedly calls
deep_twin on a STRING local will run out of memory.  The problem is that
the call to deep_twin calls `edclone' which has a call to EIF_EO_STORE_LOCK
to lock a mutex.  This macro also sets `thread_can_launch_gc' to 0 and the
corresponding unlock sets it back to 1.  So when `edclone' calls a routine
that wants to invoke the GC, it can't because GC capability is turned off
temporarily for that thread.

It seems to me that in this case the run-time should record the fact that
the thread wanted to trigger a GC cycle (but could not) and then after the call
to EIF_EO_STORE_UNLOCK it should check this flag and if set, clear it and
then trigger a GC cycle.  This doesn't sound too hard.

The workaround is to put explicit calls to `collect' or `full_collect' in
appropriate places if one has a program that exhibits this undesirable
behavior (running out of memory unexpectedly).