scoped memory management

[Tobias <ub...@gmx.net>]

can someone clarify if the memory management (memory manager interface) is 
meant for scoping.
IMHO it's not and I am willing to make it scopable.

I want to pass scoped memory managers to certain helper functions 
(xercesc/util/...)
and think that this only works in non-exceptional or catch-all 
circumstances.
If those functions (e.g. XMLString::parseInt) throw an exception the scoped 
memory manager
is passed via ThrowXMLwithMemMgrXXX to the exception during construction.
The exception allocates memory for its internal buffers (message/source 
file) from that memory manager.
If the exception is not caught before the scoped memory manager goes 
out-of-scope,
dereferencing/deallocating the memory during reporting/destruction yields 
undefined behaviour.

IMHO exceptions should allocate memory for their interal buffers from a 
static memory manager:
Exceptions should query the memory manager interface via a new virtual 
function for some kind of "global" memory manager instance.
In the memory manager default implementation this function just returns the 
this-pointer to ensure backward compatibility.
Scoped memory managers now have the change to override it and delegate 
requests to a static memory manager, e.g. XMLPlatformUtils::fgMemoryManager.

I think the best approach to make the memory management scopeable is
1. to add a method "virtual MemoryManager* getGlobalMemoryManager()" to the 
MemoryManager interface that returns the this-pointer
2. to add a call to getGlobalMemoryManager in the XMLException constructor 
for the memory manager instance passed in as a parameter and
save and use the "global" memory manager instance instead of the passed 
memory manager instance.

does anyone has a different suggestion or can confirm this approach,
so that I can fill out a feature request and provide the patches??

regards
tobias 


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: scoped memory management

[Tobias <ub...@gmx.net>]

Dave wrote:
> I was thinking of something similar, but decided that exceptions should 
> _always_ use the static MemoryManager instance.  Your idea will certainly 
> work, but can you think of a real use case where this would be valuable?
> ...
> ...
> It would certainly work, although I wonder if it the function should 
> really be called "getExceptionMemoryManager," since the global 
> MemoryManager instance is always available through the static pointer.  It 
> could be confusing if an implementation returned something other than the 
> global instance, and a user thought they were really getting the global 
> one.
>

I agree in renaming it to "getExceptionMemoryManager" or whatever name makes 
its intention more obvious to the user.
But in my opinion it's a much cleaner and more usable approach manifesting 
this special case into the pluggable memory management API than
using an unwritten convention like always using the global memory manager 
instance for exceptions.

The main reason for this approach is the requirement to have fine-grained, 
pluggable control over the memory allocations
not only for normal program flow but in exceptional circumstances as well.
This enables one to form a hierarchy of memory manager instances for each 
exception-scope
in almost the same manner as in the normal, non-exceptional scope this is 
about.

use cases for this are a thread-specific and/or multiple nested memory 
manager instances that
can serve memory requests of exceptions without synchronizing with the 
global memory manager.

an additional useful side-effect is that all remaining allocation requests 
on the global memory manager (after initialization)
could be thought of as a gap in the memory management hierarchy for 
diagnostic purposes.

tobias


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: scoped memory management

[David Bertoni <db...@apache.org>]

Tobias wrote:
> can someone clarify if the memory management (memory manager interface) 
> is meant for scoping.
> IMHO it's not and I am willing to make it scopable.
> 
> I want to pass scoped memory managers to certain helper functions 
> (xercesc/util/...)
> and think that this only works in non-exceptional or catch-all 
> circumstances.
> If those functions (e.g. XMLString::parseInt) throw an exception the 
> scoped memory manager
> is passed via ThrowXMLwithMemMgrXXX to the exception during construction.
> The exception allocates memory for its internal buffers (message/source 
> file) from that memory manager.
> If the exception is not caught before the scoped memory manager goes 
> out-of-scope,
> dereferencing/deallocating the memory during reporting/destruction 
> yields undefined behaviour.
Yes, I ran into this when I was using Xerces-C's pluggable memory 
management as well.

> 
> IMHO exceptions should allocate memory for their interal buffers from a 
> static memory manager:
> Exceptions should query the memory manager interface via a new virtual 
> function for some kind of "global" memory manager instance.
> In the memory manager default implementation this function just returns 
> the this-pointer to ensure backward compatibility.
> Scoped memory managers now have the change to override it and delegate 
> requests to a static memory manager, e.g. 
> XMLPlatformUtils::fgMemoryManager.
I was thinking of something similar, but decided that exceptions should 
_always_ use the static MemoryManager instance.  Your idea will certainly 
work, but can you think of a real use case where this would be valuable?

> 
> I think the best approach to make the memory management scopeable is
> 1. to add a method "virtual MemoryManager* getGlobalMemoryManager()" to 
> the MemoryManager interface that returns the this-pointer
> 2. to add a call to getGlobalMemoryManager in the XMLException 
> constructor for the memory manager instance passed in as a parameter and
> save and use the "global" memory manager instance instead of the passed 
> memory manager instance.
It would certainly work, although I wonder if it the function should really 
be called "getExceptionMemoryManager," since the global MemoryManager 
instance is always available through the static pointer.  It could be 
confusing if an implementation returned something other than the global 
instance, and a user thought they were really getting the global one.

> 
> does anyone has a different suggestion or can confirm this approach,
> so that I can fill out a feature request and provide the patches??
I'm willing to review and commit the patch, if others agree it would be useful.

Dave

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org