<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.6000.16544" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>Hi
Bogdan,</FONT></SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>Thanks
for looking into this. Your concern about msg_off_ seems valid, though I didn't
track down why it's like that. Your approach to solve the allocation problems
seems to be good.</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>For
docs on how to work with the ACE team you can hunt around <A
href="http://www.cs.wustl.edu/~schmidt/ACE.html">http://www.cs.wustl.edu/~schmidt/ACE.html</A>.</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>When
you have fixes, you can do one of two things:</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>1.
Create a Bugzilla entry for the problem and attach your patches (unified diff is
best) to the entry. This is the safest way to make sure it doesn't get
lost.</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>2.
Send the diffs to the ace-users list and ask for someone to integrate. This can
work for very small issues, but this Log_Msg issue is not going to be that
small.</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff size=2>Be
patient (which you have been all along!) since whomever picks up your fixes to
integrate them will implicitly take responsibility for any errors that show up
on the scoreboard (not many people have access to the 50 or so platform
combinations to test first, so it's not uncommon for a problem to show up). If
people don't have much free time, they can be a bit hesitant to take
responsibility for fixing any resultant problems. This particular ACE_Log_Msg
fix will be more desireable to fix than usual because of the performance
implications, but still, someone has to take responsibility for
it.</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff
size=2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=096371923-29112007><FONT face=Arial color=#0000ff
size=2>-Steve</FONT></SPAN></DIV><!-- Converted from text/plain format -->
<P><FONT size=2>--<BR>Steve Huston, Riverace Corporation<BR>Want to take ACE
training on YOUR schedule?<BR>See <A
href="http://www.riverace.com/training.htm">http://www.riverace.com/training.htm</A><BR></FONT></P>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Bogdan Graur
[mailto:bgraur@gmail.com] <BR><B>Sent:</B> Wednesday, November 28, 2007 3:26
PM<BR><B>To:</B> Steve Huston<BR><B>Cc:</B> 'Douglas C. Schmidt';
ace-users@cse.wustl.edu<BR><B>Subject:</B> Re: [ace-users] [usage question]
ACE_Log_Msg / ACE_Log_Record - no allocator<BR><BR></FONT></DIV>Hello
all,<BR><BR>Thanks Steve for your answer!<BR>I am analyzing now the code in
order to do the fix and found that ACE_Log_Msg::msg_off_ member is declared
static. I do not think this is a good idea considering that ACE_Log_Msg class
is used from different threads (it is used unprotected in ACE_Log_Msg::log()
method) There is also some confusion about it in the code: it is used some
times 'like' a non-static member (this->msg_off_) and some times 'like' a
static one (ACE_Log_Msg::msg_off_).<BR><BR>1. Considering that ACE_Log_Msg is
kept in TSS I think it is OK to make member 'msg_off_' non-static.<BR>2.
Proposed fix for the every-time alloc/free (general idea):<BR><BR>a) use an
ACE_Log_Record* instead of ACE_TCHAR* to store the log line;<BR><BR>b) declare
a new constructor for the ACE_Log_Record that takes as input the size to
allocate for the inner buffer (currently all ACE_Log_Record ctors allocate as
many bytes as ACE_Log_Msg needs but we shouldn't hard code this dependency
between Log_Msg and Log_Record, a future change of either of one will lead to
the change of the other one);<BR><BR>c) allocate the Log_Record once (in the
ctor) and delete once (in destructor)<BR><BR>Can someone point me to a page
describing the process to follow when posting a fix?<BR><BR>Best
regards,<BR>Bogdan<BR><BR><BR>Steve Huston wrote:
<BLOCKQUOTE cite=mid011301c8313d$11871290$6601a8c0@hope type="cite"><PRE wrap="">Hi Bogdan,
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">First I'd like to thank you for your prompt reply!
Second, I'd like to apologize for not using the the PRF (I
thought it is
not necessary as it was a usage question). Please find it at
the end of my e-mail.
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
Thanks!
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">I know now that each thread has its own ACE_Log_Msg instance kept in
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">TSS. Thanks for pointing this out!
But, inside the method:
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">ssize_t
ACE_Log_Msg::log (const ACE_TCHAR *format_str,
ACE_Log_Priority log_priority,
va_list argp)
</PRE></BLOCKQUOTE><PRE wrap="">an ACE_Log_Record is instantiated on the stack for which the
constructor
used allocates 'another' 4 KB of data. The ACE_Log_Msg
internal buffer
is afterwards copied ( ACE_OS::strcpy) in the internal buffer of
ACE_Log_Record.
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
Right... The ACE_Log_Record here used to have it's data as a member
array, and so was allocated off the stack. This was changed, from what
I can see, at:
Tue Mar 28 21:30:01 UTC 2006 jiang,shanshan
<A class=moz-txt-link-rfc2396E href="mailto:shanshan.jiang@vanderbilt.edu"><shanshan.jiang@vanderbilt.edu></A>
* ace/Log_Msg.{h,cpp}
* ace/Log_Record.{cpp,h,inl}:
Updated these files to solve the stack overflow problem in
ACE_Log_Msg
and ACE_Log_Record. Moves buffers that can be large in stack
in malloced
memory.
Thanks to qwerty <qwerty0987654321 at mail dot ru> for
motivating and
suggesting the fix to this problem.
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">I made a simple test program, ran 'gdb' on it and found that
each time
this function is invoked, the ACE_Log_Record's constructor
gets called
and its underlying data is allocated at a different address
(to try to
rule out some overloaded 'operator new' I couldn't identify).
Please tell me if there is something I missed. Thank you!
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
Nope, you got it right, but the above work to remove the MAXLOGMSGLEN
size restriction could have been done much better to avoid the
every-time alloc/free. I believe this can be done in a much more
efficient manner. One possible idea is to replace the msg_ array in
ACE_Log_Msg with a ACE_Log_Record, but I haven't traced all the
possibilities out to see if this is a good solution. If you can work
out the details of this, that would be great. If you don't have
time/energy to do this, please record this info in Bugzilla or
consider partnering with someone who can analyze the situation and
develop a good fix for it.
Thanks very much for raising this and analyzing the source of the
excessive memory allocations.
Best regards,
-Steve
--
Steve Huston, Riverace Corporation
Want to take ACE training on YOUR schedule?
See <A class=moz-txt-link-freetext href="http://www.riverace.com/training.htm">http://www.riverace.com/training.htm</A>
</PRE>
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite"><PRE wrap="">
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">On my understanding each time you log something using ACE_Log_Msg
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=""><!---->
</PRE>
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite"><PRE wrap="">another ACE_Log_Record is created which in turn creates
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap="">its underlying
</PRE>
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite"><PRE wrap="">data (4 KB) on the heap. This can happen very often and may have
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=""><!---->a
</PRE>
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite"><PRE wrap="">negative impact on the overall performance of the application.
</PRE></BLOCKQUOTE><PRE wrap="">No, that's incorrect. the 4 KB of data is allocated using
thread-specific storage (see the discuss in the POSA2 book at
<A class=moz-txt-link-abbreviated href="http://www.cs.wustl.edu/~schmidt/POSA/POSA2/">www.cs.wustl.edu/~schmidt/POSA/POSA2/</A>), so the 4 KB is
</PRE></BLOCKQUOTE><PRE wrap="">allocated only
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">once for each thread.
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">Is there a way to control the allocation of ACE_Log_Record
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap="">data without
</PRE>
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite"><PRE wrap="">overloading the global new operator?
</PRE></BLOCKQUOTE><PRE wrap="">No, but this shouldn't be necessary, as per the discussion above.
Thanks,
Doug
</PRE></BLOCKQUOTE><PRE wrap="">_______________________________________________
ace-users mailing list
<A class=moz-txt-link-abbreviated href="mailto:ace-users@mail.cse.wustl.edu">ace-users@mail.cse.wustl.edu</A>
<A class=moz-txt-link-freetext href="http://mail.cse.wustl.edu/mailman/listinfo/ace-users">http://mail.cse.wustl.edu/mailman/listinfo/ace-users</A>
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>