RE: [jreed@xxxxxxxxxxxx: Csharp module and memory pressure on GC]

>-----Original Message-----
>From: Fulton, William 
>Sent: 23 September 2004 09:21
>To: Swig (E-mail)
>Cc: 'jreed@xxxxxxxxxxxx'
>Subject: FW: [jreed@xxxxxxxxxxxx: Csharp module and memory pressure on
>GC]
>
>
>
>
>-----Original Message-----
>From: Joel Reed [mailto:jreed@xxxxxxxxxxxx]
>Sent: 22 September 2004 22:12
>To: Fulton, William
>Subject: [jreed@xxxxxxxxxxxx: Csharp module and memory pressure on GC]
>
>
>William, another msg caught by swig's spam traps. Thought you
>might be interested since it is C# related.
>
>----- Forwarded message from Joel Reed <jreed@xxxxxxxxxxxx> -----
>
>> From: Joel Reed <jreed@xxxxxxxxxxxx>
>> Subject: Csharp module and memory pressure on GC
>> 
>> This is a complicated issue involving the .Net garbage
>> collector, and swigCPtr's.
>> 
>> Problem: 
>> 
>> 1) create two c++ classes where 1 class uses
>> the facilities of another. eg:
>> 
>> class o_dbc {
>> };
>> 
>> class o_dim {
>>   public: o_dim(o_dbc& db);
>> };
>> 
>> 2) generate csharp wrappers for these classes 
>> 
>> 3) use these classes while creating enough memory
>> pressure on the garbage collector such that one of the
>> objects is reclaimed, even though the other object
>> still has a swigCPtr reference to the just reclaimed object.
>> (we generated this reclaimation with 6 to 10 65k strings)
>> 
>> 4) as soon as the still-live object tries to use
>> the swigCPtr to the reclaimed object, an exception occurs.
>> 
>> I'm wondering if swig's outputted csharp code could be 
>> augmented such that an object which uses getCPtr from another 
>> object could setup a HandleRef or GCHandle so that the CLR
>> would be informed that the objects depend upon each other,
>> preventing either from being prematurely reclaimed. 
>> 
>> I changed by hand the swig *.cs files and using HandleRef 
>> does fix the problem. My only concern now is if I know 
>> enough swig internals to make a patch...
>> 
>> jr
>

Firstly, a suggestion on a way of thinking. Only on very rare occasions should 
it be necessary to post process the generated files. There is a way to control 
nearly all aspects of SWIG's code generation.

I wouldn't consider setting up a GCHandle for all classes that are input 
parameters as the overhead is likely to be too great. You have a shallow copy 
being stored in your class, which is not very common and making shallow copies 
is one of the few time you will run into the problem you have.

Depending exactly on how you want to solve this, you could supply a new 
"csbody" / "csbody_derived" typemap or add some code in using a "cscode" 
typemap. The code in the o_dim(o_dbc& db) constructor can be modified using the 
"csin" typemap. For example, I have a similar siutation where the input 
parameter is stored in a C++ collection and the memory is controlled by a C++ 
class, so the GC must not delete the underlying C++ memory when/if it is 
collected.

%typemap(csin) o_dbc& db "$&csclassname.getCPtrAndRelinquishOwnership($csinput)"
%typemap(cscode) o_dbc %{
  internal static IntPtr getCPtrAndRelinquishOwnership($csclassname obj) {
    IntPtr ptr = IntPtr.Zero;
    if (obj != null) {
      ptr = obj.swigCPtr;
      obj.swigCMemOwn = false;
    }
    return ptr;
  }
%}

The above adds a getCPtrAndRelinquishOwnership() method to the o_dbc class and 
the o_dim constructor generated is then:

  public o_dim(o_dbc db) : 
this(examplePINVOKE.new_o_dim(o_dbc.getCPtrAndRelinquishOwnership(db)), true) {
  }

You should be able to add in your HandleRef using the same approach with these 
typemaps and if you need to modify the Dispose methods use the "csdestruct" / 
"csdestruct_derive" or "csfinalize" typemap. See the defaults in csharp.swg as 
a starting point.

If you post the diffs between what gets generated by default and the desired 
code, I can probably set the typemaps up for you.

William

Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.

_______________________________________________
Swig maillist  -  Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig