a NULL allocator. This gives us a single, central place to handle out-of-memory
errors (by, for example, throwing an exception) for basically all of epan.
The only remaining glib memory that is directly allocated is for the hash tables
used by the simple and strict allocators.
svn path=/trunk/; revision=51627
makes canary checking about 20% faster, which should speed up fuzz-testing now
that more and more dissectors use wmem.
svn path=/trunk/; revision=51620
header later causes it to be redefined - as happens on my Solaris 11
virtual machine - we get a redefinition warning, which gets treated as
an error.
svn path=/trunk/; revision=51344
Make epan_free a no-op if the pointer is NULL. This fixes 99% of the cases
causing problems for wmem_leave_file_scope() - remove that XXX comment and add
back the assertion.
Remove the cleanup_dissection call from epan_cleanup, it doesn't make sense
there. init_dissection is only called from epan_new, so cleanup_dissection
should only be called from epan_free.
Add one missing epan_free call to tshark revealed by the above changes.
svn path=/trunk/; revision=51342
consistency (they are called just once and will be inlined by any reasonable
compiler).
Also add some comments, fix some spacing etc. No functional changes.
svn path=/trunk/; revision=51304
doubly-linked list at the head of each block. This was intended as a step
towards supporting allocations bigger than the usual block size, but also shows
up as a 2% performance improvement in the speed test, so win-win.
svn path=/trunk/; revision=51298
../../epan/wmem/wmem_user_cb.h:52:11: error: parameter 'allocator' not found in the function declaration
[-Werror,-Wdocumentation]
* @param allocator The allocator that triggered this callback.
^~~~~~~~~
../../epan/wmem/wmem_user_cb.h:53:11: error: parameter 'event' not found in the function declaration
[-Werror,-Wdocumentation]
* @param event The event type that triggered this callback.
^~~~~
../../epan/wmem/wmem_user_cb.h:54:11: error: parameter 'user_data' not found in the function declaration
[-Werror,-Wdocumentation]
* @param user_data Whatever user_data was originally passed to the call to
^~~~~~~~~
../../epan/wmem/wmem_user_cb.h:63:11: error: parameter 'recurring' not found in the function declaration
[-Werror,-Wdocumentation]
* @param recurring If this is FALSE then the callback is called exactly once.
^~~~~~~~~
4 errors generated.
svn path=/trunk/; revision=51259
bother splitting. This greatly simplifies the logic, trims another 4% off the
fast path, and doesn't actually affect the results at all because of the way we
pad for alignment anyways.
svn path=/trunk/; revision=51216
if the right-hand merge target was there originally. This brings memory usage
down another ~40% when running the heavy test suite.
This also lets us extract the master-list check out of unfree() since it is now
only relevant at a single caller, and turns unfree into the more understandable
remove_from_recycler().
svn path=/trunk/; revision=51104
Removes one branch from the hot path, deduplicates one function call in the cold
path by effectively falling through, and makes it more obvious what the code is
actually trying to do.
svn path=/trunk/; revision=51013
to override that to simple for valgrinding (we still force the allocator in the
allocator and timing tests, of course).
svn path=/trunk/; revision=50971
Move a few assignments around to avoid one extra subtraction. I suspect having
the two if statements next to each other is friendly to the compiler's optimizer
as well.
Shaves ~1.3% off my timing tests, bringing the new design *very* close to the
old one in raw allocation speed.
svn path=/trunk/; revision=50961
unobtrusive if statement got dropped. Without it the allocator exhibits the old
bad behaviour of 3x memory usage and heavy fragmentation.
We want it back, thank you very much.
svn path=/trunk/; revision=50960
What was becoming apparent as more dissectors started using wmem was that the
old block allocator design had issues with memory fragmentation. This keeps the
same underlying memory layout, but completely changes how free blocks are kept.
It runs about 3% slower in my tests (still an order of magnitude faster than
g_malloc) but uses about 1/3 the memory.
I suspect some simple optimizations could reclaim that 3% as well - the design
is fast, but I did not code particularly for speed.
Thoroughly tested with the existing test suite (which caught half a dozen bugs
in my first draft) so it should actually work!
svn path=/trunk/; revision=50955
The overhead is not large, and it makes append much faster (O(1) vs O(n)).
It also will make a queue easy to add, which I need for a dissector I'm
writing...
svn path=/trunk/; revision=50744
From the comment above wmem_tree_insert32_array():
* If you use ...32_array() calls you MUST make sure that every single node
* you add to a specific tree always has a key of exactly the same number of
* keylen words or things will most likely crash. Or at least that every single
* item that sits behind the same top level node always have exactly the same
* number of words.
So clearly generating thousands of keys with random lengths while testing is
going to cause problems. Generate a set of random lengths, then use those
lengths consistently (but still generating random keys of those lengths).
Should hopefully fix the intermittent build-bot failures.
(unfortunately this does not manifest nicely, and I cannot see an easy way to
assert it so that we catch other people trying to use different-length key
subtrees)
svn path=/trunk/; revision=50184
Put in a whole bunch of stderr output in the wmem tree tests in the hopes that
the next time one of the buildbots randomly (and irreproducibly) fails on this
step we'll have at least a bit of a hint as to where it happened.
svn path=/trunk/; revision=50131
Evan Huus