Hi Michael,
Thanks for your feedback. For many of the committers (certainly for me!),
this was a first experience implementing a pluggable memory management
scheme; so it's useful to know about the possible pitfalls about the
approach that we've taken.
Among other things, you state in your e-mail:
> Do what you like; I'm not interested in proposing an allocator for
Xerces.
As a Xerces user, I imagine you're interested in having the most reliable,
best-performing XML processor possible. If you believe that the
implementation we've made here is suboptimal, I certainly hope you will
consider proposing a different approach. Whatever its shortcomings, it
seems to me that the approach is quite modular; so it seems to me that it
shouldn't be inherently that difficult to propose an alternative
implementation. I don't think anyone here believes there are no
shortcomings to the approach we've selected; so if you come up with an
alternative that performs competitively and is more robust, I'm certain it
would be considered.
This is open-source after all; we'll all have better products if we work
together to make them better.
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
|---------+------------------------------->
| | Michael Wojcik |
| | <[EMAIL PROTECTED]|
| | ofocus.com> |
| | |
| | 05/23/2003 09:47 AM |
| | Please respond to |
| | xerces-c-dev |
| | |
|---------+------------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: RE: New memory manager alignment issues?
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 22, 2003 1:11 PM
>
> [I wrote:]
> > And what if some type on some platform has stricter alignment
> > requirements than either double or void*?
>
> But it may be the best we can do...
"best" is subjective. Clearly you and I have different criteria. Under
mine, the solutions proposed so far are poor at best.
> I'm not sure i agree this will be a minor performance hit.
Well, obviously that depends on many factors, such as how the allocator's
used by Xerces for particular data sets and application operations, what
else the application does, and what constitutes a "minor" performance hit.
Until someone profiles it, we won't know; and even then we'll only know for
those particular conditions.
> At the very least, this will require synchronized access to a
> global, static hashtable. That means one synchronization per memory
> allocation, which will have a major impact on performance.
Pure supposition, since we have no context for evaluating performance. And
since memory allocation is already expensive, it's not immediately obvious
that the additional synchronization will have "a major impact".
> With regard to buffer under-run and over-run, I'm not terrible
> sympathetic with applications that do this, as the C++ standard
> says this results in undefined behavior.
And I'm not terribly sympathetic with people who aren't interested in
considering the probable behavior of code defects. That's largely what's
responsible for the huge number of exploitable buffer-overrun
vulnerabilities in C and C++ programs.
> Since that's the case, is this implementation really reduced
> functionality compared to the standard run-time?
Did I claim it was? Though since you raise the issue, yes, because it
produces undefined behavior by forcing objects to an alignment which may
not
be appropriate. That has nothing to do with defensive coding to reduce the
possibility of exploitable buffer overruns, of course.
Do what you like; I'm not interested in proposing an allocator for Xerces.
That's a problem which is properly left to the implementation. I merely
wanted to point out that the proposed one duplicates two problems that are
well-known in this area, and no one discussing it seemed to be very
familiar
with them. As a Xerces user, I can't say that this thread has made me very
comfortable about the future of the project.
--
Michael Wojcik
Principal Software Systems Developer, Micro Focus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
