Re: [Oorexx-devel] When must one use DeleteLocalReference() ?
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.atwrote: 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
Re: [Oorexx-devel] When must one use DeleteLocalReference() ?
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.comwrote:
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
Re: [Oorexx-devel] When must one use DeleteLocalReference() ?
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.comwrote:
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
Re: [Oorexx-devel] When must one use DeleteLocalReference() ?
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.atwrote:
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.comwrote:
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
Re: [Oorexx-devel] When must one use DeleteLocalReference() ?
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
