[
https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13469965#comment-13469965
]
Mary hinton commented on PROTON-57:
-----------------------------------
Thanks for the feedback,
We could substitute the alloca() for memory allocation that is not in a loop as
long as the buffers are reasonable sizes.
Since alloca() acquires new stack space each time it's called without reusing
space from previous calls, it's not a good idea to use it inside a loop.
The problem with anything being allocated out of the stack is the size of the
allocation. Stack space can still run out and alloca() will not warn us of a
problem. Using a loop in Linux containing a VLA to reallocate stack space, you
can still get segmentation failure if the allocation is large enough. Also if
large messages have been allocated on the stack, the memory can be reused, but
my understanding is that the stack doesn't shrink. The only way to recover
stack memory is when the thread exits.
I notice proton is initially set up with a stack space size of 10000000, so it
may be expecting lots of large messages. I didn't know how many threads are
being created to handle buffers allocated out of the stack and if the number of
threads could be a problem for stack space usage.
Here's a snippet of code using the macros proposed:
Changed char data[ctx->size + 16];
server_callback()
{
char tagstr[1024];
char msg[10*1024];
PN_VLA(char, data, ctx->size + 16);
...
PN_VLA_FREE(data);
}
I saw various web sites arguing the pros and cons of VLAs, so maybe it is a
good idea to discuss VLAs in their own Jira thread.
> Proton porting problems between current codebase and Visual Studio 2010
> toolset
> -------------------------------------------------------------------------------
>
> Key: PROTON-57
> URL: https://issues.apache.org/jira/browse/PROTON-57
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: Windows using Visual Studio 2010
> Reporter: Mary hinton
> Labels: build
>
> This thread will be used to discuss the porting problems encountered using
> Visual Studio 2010
> Here’s the first one to discuss:
>
> 1. Visual Studio doesn’t support variable length arrays.
> a. Currently using malloc()/realloc() in my port just to get it to
> compile and be able to report memory allocation errors. This is not what I
> want to submit to the proton group for memory allocation.
> b. Cliff had a good method that included setting up macros and replace
> the VLAs with alloca() in the Windows version, but it could still cause
> problems when the stack overflowed. VLAs can also run out of stack space.
> c. _malloca() should be a better way than _alloca() on Visual Studio.
> Any messages under 1K would be allocated out of the stack. Over 1K will use
> heap. If the average messages are under 1K, this may be the most efficient
> way in Visual Studio. _malloca() also has new security enhancements.
> 1. Using _malloca() in the Windows version and VLA in Linux would
> require two macros. The major difference for the Linux version would be to
> use the new macro for VLA and to include the new free macro even though there
> is nothing to free using VLA. In Visual Studio, _freea(buf) will not free
> anything if it is allocating off the stack.
> Linux can continue to use VLAs.
> #ifdef C99
> #define PN_VLA(TYPE, buf, size) TYPE buf[size]
> #define PN_VLA_FREE
> #else
> #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*)
> _malloca(size)
> #define PN_VLA_FREE(buf) _freea(buf)
> #endif
> d. If the average size messages to allocate out of the stack needs to be
> increased for performance reasons, we can set up a new memory model. The 1K
> is not adjustable for _malloca().
> We can set up new macros along the lines of Microsoft’s suggestion below.
> “I would suggest something similar to what ATL does. Use alloca for small
> (where you define what that is) sizes and use heap allocation for larger
> ones. You can wrap the logic inside of a class or macros. To work around
> the fact that alloca isn't cleaned up at block scope, rewrite the block into
> functions or use lambdas. (I think alloca works inside of lambdas.)”
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
