PR# 14464 Multithreaded program that calls {STRING}.deep_twin runs out of memory

A multithreaded program has one main thread and one worker thread.
The worker thread creates a STRING, stores it in an  attribute  and then 
repeatedly calls deep_twin on the attribute and assigns it back into the
same attribute.  If called with argument 1 10000 (one worker thread, and
STRING to be deep-twinned has capacity 10000), it uses 1 GB before
it finishes.  Surely there is something wrong here.

A similar program that is not multithreaded uses only about 20 MB.

Finalize with attached classes and config file.
Execute system with arguments 1 10000.
System execution ends normally, but system is using about 1 GB just before it
   finishes.

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).

Attachments for problem report #14464