Nop, your analysis is correct. The return value (if is exists) is also a
potential memory leak. This probably doesn't show up as a problem because
the RoutineObjects take up a fairly substantial amount of memory.
Rick
On Wed, Jun 26, 2013 at 2:32 PM, Mark Miesfeld <miesf...@gmail.com> wrote:
> Thanks Rick.
>
> I started writing a reply based on my experiences so far, but I know you
> could explain it better.
>
> I have one question based on Rony's code:
>
> void executeProgram(RexxThreadContext *threadContext, char *fname, char
> *code)
> {
> RexxRoutineObject rro=threadContext->NewRoutine(fname, code,
> (size_t) strlen(code));
> RexxObjectPtr rop=threadContext->CallRoutine(rro, NULL); //
> call the program without args
> threadContext->ReleaseLocalReference(rro);
> }
>
> In the above, he is not releasing rop, which would be the returned object
> from CallRoutine(). But only releasing rro seemed sufficient in his case
> to solve the problem.
>
> rop will also have a local reference won't it. And also be stored in
> table of local references. That should also have a release shouldn't it?
> Each iteration in the loop will return a new Rexx object from called
> routine won't it? Or is there some reason why rop is not set with a local
> reference?
>
> --
> Mark Miesfeld
>
>
>
> On Wed, Jun 26, 2013 at 11:19 AM, Rick McGuire <object.r...@gmail.com>wrote:
>
>> The interpreter knows nothing about any of the references you have in
>> your C code. Those are just normal pointers, so nothing happens to let the
>> interpreter know that those pointers are out-of-context. The only
>> mechanism the interpreter has available is the context object used to
>> provide the api access. That context object will keep a reference to all
>> objects returned from API calls (e.g. a "local reference"). These objects
>> are thus protected from garbage collection until the context is destroyed.
>> Method, call, and exit contexts are destroyed when you return from the
>> appropriate call out. Thread contexts for attached threads will be
>> destroyed when you detach the thread. The main thread context obtained by
>> creating an interpreter instance will only be destroyed when the instance
>> is destroyed.
>>
>> For most uses, you generally don't need to bother with releasing this.
>> When you return from the method/call/exit, the references will be released
>> automatically. However, if you are creating large numbers of objects (for
>> example, in a loop), you probably should consider releasing the references.
>> The situation you raised originally is a good example, since you were
>> causing a memory leak by never releasing the references for the objects you
>> no longer needed.
>>
>> Mark Miesfeld ran into a situation with his sql lite implementation. In
>> his situation, he was creating a large number of string objects and adding
>> them to a collection object. All of the objects he was creating were added
>> to the collection, so none of them were eligible for collection, but Mark
>> started running into memory issues because the table used to keep all of
>> the local references grew to an enormous size. The solution here was to
>> release the local references after they were added to the collection. Not
>> because the objects were no longer needed, but because the local C
>> reference to the was no longer needed.
>>
>> Rick
>>
>>
>> On Wed, Jun 26, 2013 at 1:52 PM, Rony G. Flatscher <
>> rony.flatsc...@wu.ac.at> wrote:
>>
>>> This question may be of interest for other developers as well, so
>>> moving/asking it to the ooRexx
>>> developer list:
>>>
>>> While experimenting with a little C++ program, there would be a
>>> RexxRoutineObject created using
>>> NewRoutine() which then got executed with CallRoutine() many thousand
>>> times. While doing so memory
>>> consumption constantly increased, even when placing the two statements
>>> in a function of their own.
>>> Therefore I thought there was a memory leak in ooRexx and filed a bug,
>>> which was invalid.
>>>
>>> The solution Rick pointed at was to use DeleteLocalReference() on the
>>> RexxRoutineObject such that it
>>> can be garbage collected, and in effect, this solves the problem!
>>>
>>> ---
>>>
>>> So far, I have been thinking, that if any RexxObject went out of scope
>>> (of a block, of a function)
>>> it got automatically released for the garbage collector.
>>>
>>> Under which conditions must/should one use ReleaseLocalReference() ?
>>>
>>> ---rony
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
