Mailing-List: contact etch-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: etch-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of ThomasMarsh@gamestop.com
 designates 12.25.107.28 as permitted sender)
From: Thomas Marsh <ThomasMarsh@gamestop.com>
To: "etch-dev@incubator.apache.org" <etch-dev@incubator.apache.org>
Subject: Etch/C Memory Consumption
Thread-Topic: Etch/C Memory Consumption
Thread-Index: AcxxivBi5BxEJeFwTuaXOAvn2ve90g==
Date: Mon, 12 Sep 2011 21:19:46 +0000
Message-ID: <9711F93A3E3A3C458276A476FFA91AECC22BAF@GV1HQPEX03.babgsetc.pvt>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_9711F93A3E3A3C458276A476FFA91AECC22BAFGV1HQPEX03babgset_"
MIME-Version: 1.0

--_000_9711F93A3E3A3C458276A476FFA91AECC22BAFGV1HQPEX03babgset_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello all,

I have a question about memory consumption in the Etch/C runtime based on b=
ehavior we are seeing within our C client. I have modified the C implementa=
tion of the HelloWorld example in the distribution to run an infinite loop =
of requests:

In the main() routine of helloworld_client_main.c:

                ...
                while (1) {
                                user =3D new_helloworld_user();
                                user->id =3D 5;
                                user->name =3D new_stringw(L"User");
                                result =3D remote->say_hello(remote, user);
                                if (is_etch_exception(result)) {
                                                ...
                                }
                                printf("%S\n", result->v.valw);
                                etch_object_destroy(result);
                }
                ...

While running this, I see that the memory consumption of the client continu=
ally grows. (In this example, it grows by about 1 mB every 5 seconds.) I ca=
nnot see the memory leak when testing with valgrind, so it would suggest th=
at the leak is in Etch managed memory which is cleared at exit.

My understanding is that the call to remote->say_hello() should delegate re=
sponsibility of deallocation of the parameters to the Etch runtime, and tha=
t the client code is only responsible for deallocating the result object. T=
he memory use should be stable within this tight loop. Can anyone comment o=
n the potential cause of the memory consumption?

Thanks, and best regards,

--thomas

--_000_9711F93A3E3A3C458276A476FFA91AECC22BAFGV1HQPEX03babgset_--