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
> <mailto: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
> <mailto: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
> <mailto: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
