Again, thank you very much for your explanations and answers!
---rony
Rony G. Flatscher (mobil/e)
Am 26.06.2013 um 20:46 schrieb Rick McGuire <object.r...@gmail.com>:
> Yes, any long-lived contexts like this should be doing that sort of reference
> management. Strings are objects just like any other object. They needed to
> be managed in the same way.
>
> Rick
>
>
> On Wed, Jun 26, 2013 at 2:41 PM, Rony G. Flatscher <rony.flatsc...@wu.ac.at>
> wrote:
> Thanks a lot, Rick!
>
> In the case that a Rexx interpreter instance may be living for a long time
> (like days) and used for executing Rexx programs constantly and repeatedly,
> would it be then advisable to use DeleteLocalReference() on all RexxObject's
> one creates in native code to be sure that all RexxObjectPtr get garbage
> collected? How about RexxStrings (there are of course many such instances
> that might get created in native code) or external ooRexx functions that
> return RexxObjectPtr?
>
> ---rony
>
>
>
> On 26.06.2013 20:36, Rick McGuire wrote:
>> 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
