[Ace-users] [ace-users] [usage question] ACE_Log_Msg / ACE_Log_Record - no allocator

[Steve Huston]

Hi Bogdan,

> 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.

Thanks!

> I know now that each thread has its own ACE_Log_Msg instance kept in

> TSS. Thanks for pointing this out!
> 
> But, inside the method:
> > ssize_t
> > ACE_Log_Msg::log (const ACE_TCHAR *format_str,
> >                   ACE_Log_Priority log_priority,
> >                   va_list argp)
> 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.

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
<shanshan.jiang at vanderbilt.edu>

        * 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.

> 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!

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 http://www.riverace.com/training.htm

> >   
> >> On my understanding each time you log something using ACE_Log_Msg

> >> another ACE_Log_Record is created which in turn creates 
> its underlying 
> >> data (4 KB) on the heap. This can happen very often and may have
a 
> >> negative impact on the overall performance of the application.
> >>     
> >
> > No, that's incorrect.  the 4 KB of data is allocated using
> > thread-specific storage (see the discuss in the POSA2 book at
> > www.cs.wustl.edu/~schmidt/POSA/POSA2/), so the 4 KB is 
> allocated only
> > once for each thread.
> >
> >   
> >> Is there a way to control the allocation of ACE_Log_Record 
> data without 
> >> overloading the global new operator?
> >>     
> >
> > No, but this shouldn't be necessary, as per the discussion above.
> >
> > Thanks,
> >
> > Doug
> >   
> 
> _______________________________________________
> ace-users mailing list
> ace-users at mail.cse.wustl.edu
> http://mail.cse.wustl.edu/mailman/listinfo/ace-users
>