aboutsummaryrefslogtreecommitdiffstats
path: root/epan/wmem
AgeCommit message (Collapse)AuthorFilesLines
2014-08-18Fix warning: no previous prototype for ... [-Wmissing-prototypes]Alexis La Goutte1-0/+1
Change-Id: I59e744d905a0a13eea4ff649a984b2ed9f1f51e7 Reviewed-on: https://code.wireshark.org/review/3697 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-08-04Try to detect overflow without causing signedness warnings.Evan Huus1-1/+1
Change-Id: I957ead1f674e2c56e9c741841fea11395769b238 Reviewed-on: https://code.wireshark.org/review/3398 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-08-04Check for multiplicative overflow in the wmem_alloc_array macros.Evan Huus1-2/+5
Bug:10343 Change-Id: Iea511c806b92999b3b497f94886c46a818100a23 Reviewed-on: https://code.wireshark.org/review/3396 Reviewed-by: Bill Meier <wmeier@newsguy.com>
2014-08-03wmem: get rid of the allocator timing testEvan Huus1-59/+0
Some of the allocators are close enough that a little bit of system load at the time of the test was enough to throw them off, and it was causing unnecessary buildbot failures. Benchmarking on real-world cases at the time of implementation (as well as reliable "average" results on the buildbots) has left me confident that block_fast is, in fact, faster than block, which is faster than simple/strict. Additionally, the allocators are effectively "done" and unlikely to change, so the possibility of uncaught performance regressions is low. Change-Id: I144ea4cd9d6000edc4075ed682ce6a4aeaf5e28a Reviewed-on: https://code.wireshark.org/review/3356 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-07-01Bump (again) the amount of work we do for wmem's timing testEvan Huus1-1/+1
Apparently the new win8 vm has a *very* low-resolution timer, and the allocators are indistinguishable at the previous amount of work. Change-Id: If4e5bb8f85b1f0d39658f54001c88f42ffddfc47 Reviewed-on: https://code.wireshark.org/review/2768 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-05-28Add Modelines and use tabs and fix typoAlexis La Goutte1-1/+1
Change-Id: Ie3f60f66f0f4a572098d1d7425c53aaf51bdb747 Reviewed-on: https://code.wireshark.org/review/1846 Reviewed-by: Michael Mann <mmann78@netscape.net>
2014-05-23Add jumbo-allocation support to wmem fast blockEvan Huus2-5/+57
As it turns out, we do occasionally need it. Bug:10115 Change-Id: Ifec79e4d2470bbc09f15674534d01418a6571a0d Reviewed-on: https://code.wireshark.org/review/1688 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-05-21Remove extra parentheses.Gerald Combs1-1/+1
Fix the clang warning epan/wmem/wmem_allocator_simple.c:49:27: error: equality comparison with extraneous parentheses [-Werror,-Wparentheses-equality] if ((allocator->count == allocator->size)) { ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~ We might want to add -Wno-parentheses-equality to the compiler flag list but I'm not sure if doing so would hide valid problems. Change-Id: Id59b55af1411f13309fbec77870f869e04a6f49f Reviewed-on: https://code.wireshark.org/review/1717 Reviewed-by: Gerald Combs <gerald@wireshark.org>
2014-05-17Fix newly optimized strdup_vprintf.Evan Huus2-5/+11
As Jakub pointed out, our +1/-1 logic for null terminators wasn't quite right. Also be sure to re-copy the va_list parameter if we need to re-use it, as otherwise things break oddly. Change-Id: Ibeaa95af602f565791e9378a6cfce434f13025eb Reviewed-on: https://code.wireshark.org/review/1670 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-05-17Fixes after wmem_strdup_vprintf() optimizationJakub Zawadzki1-7/+7
- g_vsnprintf()[1] buffer size can includes space for terminating NUL, this simplifies code, and fix problems with string truncation - g_vsnprintf() returns number of bytes without terminating NUL, so we need to do + 1 - second g_vsnprintf() call use already consumed 'ap2' va_arg, which makes wmem_strdup_vprintf() doesn't work/ crash for FORMATTED string length > 80 [1] https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g-vsnprintf Change-Id: I0ebb7f452e3e89c9b55f8ac889166f02e8a7c982 Reviewed-on: https://code.wireshark.org/review/1667 Reviewed-by: Michael Mann <mmann78@netscape.net>
2014-05-17Use a pre allocated buffer in wmem_strdup_vprintf() reduces the functionAndersBroman1-4/+21
cost by more than half. Change-Id: I6ad2ae407325d2091ffb60919cb3ed74f78f39fa Reviewed-on: https://code.wireshark.org/review/1662 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-05-13Dumber "simple" wmem allocator.Evan Huus1-39/+41
Instead of maintaining a hash table, just alloc a really big array of pointers. This is theoretically bad since it means frees and reallocs become O(n), but in practice it makes the capture from bug 10098 run about 20% faster under valgrind. This makes sense, since the workload is heavily dominated by allocations, and most frees/reallocs are recently allocated (so they will be found quickly at the beginning of the scan). Bug:10098 Change-Id: I7097ad0653d3fb5f4f723cc84046cbc4450e3494 Reviewed-on: https://code.wireshark.org/review/1602 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-05-06Increase the work used to time wmem allocatorsEvan Huus1-1/+7
It appears that on some platforms the timer underlying g_test_timer() is relatively low-precision, so the small amount of work that we were previously doing was not enough for the timer to provide a useful value. Bumping the amount of work should provide more meaningful values, and the whole timing step still takes only a few seconds. Change-Id: Idce1386eaa33add845d9a2758b0beb72bbf370d6 Reviewed-on: https://code.wireshark.org/review/1523 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-05-05Fix dead assignment found by clang in test codeEvan Huus1-1/+1
Change-Id: Ie78769bfd8034f6c2ee7d9e26a209d650cedb98d Reviewed-on: https://code.wireshark.org/review/1507 Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
2014-05-05Reduce wmem fast-block fuzz rounds even furtherEvan Huus1-1/+1
Follow-up to g19e650f43adf23b0aa92821bff0cc389643944f6 since the fuzz-bot is still failing. Change-Id: I2d05a861b0edf50ce734b682e6e3e33729bf6771 Reviewed-on: https://code.wireshark.org/review/1503 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-05-05Several tweaks to fast block allocatorEvan Huus1-45/+24
- manually inline wmem_block_fast_add_to_block_list, it was only two lines and only called twice, so the function boilerplate was outweighing the abstraction - change free_all to release all but one block to the OS immediately, making gc a no-op; the alloc logic doesn't reuse later blocks anyways, so this was effectively a leak Change-Id: I033fbb2f3d87e58c7346cba10f2c710eaaa49e9f Reviewed-on: https://code.wireshark.org/review/1499 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-05-05Fast block allocator: make wmem_block_fast_hdr_t single linked list.Jakub Zawadzki1-4/+1
Double linked list was required by jumbo allocation. No support for jumbo -> no need for double linked list -> have only 'next' pointer in header. Change-Id: I48a0f468ebba9db3a63548d8e7307b6424c759ed Reviewed-on: https://code.wireshark.org/review/1495 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-05-04Fuzz fewer iterations of the fast block allocatorEvan Huus1-6/+11
I believe the XP buildbot failures are simply running out of memory, so hopefully reducing the number of iterations should be enough to let it finish reliably. Change-Id: I40af789d528c2623e95f153529205b5e617c6e02 Reviewed-on: https://code.wireshark.org/review/1496 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-05-02wmem: add new simple block allocator, use it in packet-scope.Jakub Zawadzki7-35/+375
For packet-scope allocation, there's no need to support realloc(), free() cause memory will be garbage collected after packet dissection. (and this allocator is much faster than full block allocator). Change-Id: I73fdf708c3077f48f55bdcc71f4fa859e4ac2335 Reviewed-on: https://code.wireshark.org/review/1428 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-05-02Reintroduce wmem_allocator_force_newEvan Huus1-4/+36
We now have to call wmem_init in order to randomly seed the values for wmem_map. This means we can no longer rely on the lack of override, so we have to force the right allocator type when testing/timing the allocators themselves. Change-Id: I005034465b0a98f19876899b96ef65b3e4b1d759 Reviewed-on: https://code.wireshark.org/review/1468 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-05-02Optimize wmem_strbuf_grow.Evan Huus1-0/+8
As suggested by Anders, in the case of repeated calls to wmem_strbuf_append_c (and other functions which append very little data) the growth check was a substantial portion of the over-all running time. By short-circuiting the check in the case where growth isn't needed (as opposed to letting it fall-through naturally) we shave ~25% off the cost of such repeated calls in my benchmarks. The function (wmem_strbuf_grow) is inline, so the compiler should be able to optimize each caller individually for the short-circuit. Change-Id: I76419020f4d8fa675906eb77798969b6c61c7732 Reviewed-on: https://code.wireshark.org/review/1467 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-04-30Fix indent (Use Tab)Alexis La Goutte1-5/+5
Change-Id: I811fb3db41a31d2334eb80f1821beea109bfa0d9 Reviewed-on: https://code.wireshark.org/review/1437 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-04-29Fix an extraneous parentheses warning.Gerald Combs1-1/+1
"if (G_UNLIKELY(...))" triggers an extraneous parentheses warning when compiling with XCode's clang-500.2.75. From looking at the macro definition we *should* be able to get rid of the outer parentheses everywhere. Change-Id: I710e1cc391e1167c1243c4ddb032f2831f0a9498 Reviewed-on: https://code.wireshark.org/review/1432 Reviewed-by: Gerald Combs <gerald@wireshark.org>
2014-04-27Fix rare case of wmem map being O(n)Michael Mann1-0/+2
For 'x' equal to 0, HASH() macro also returns 0 which makes wmem map O(n). When random generator will return 0 just use 1. Change-Id: If484091352a719aea27135a705d37ff4c184a13b Reviewed-on: https://code.wireshark.org/review/1387 Reviewed-by: Michael Mann <mmann78@netscape.net>
2014-04-25Support out-of-source checkapiStig Bjørlykke1-1/+2
Always call $(top_srcdir)/tools/checkAPIs.pl with -sourcedir=$(srcdir) from Makefile.am to allow out-of-source 'make checkapi'. Change-Id: I60d7e0079984a8ededdacf4517a0738486fa7973 Reviewed-on: https://code.wireshark.org/review/1294 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-04-23Add a cast to satisfy mac buildbot.Evan Huus1-1/+1
Change-Id: I625b025d3f8a57812512497c6104977ae5d10232 Reviewed-on: https://code.wireshark.org/review/1298 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-04-23Hash map implementation for wmem.Evan Huus7-2/+562
This has two expected uses: - Many current users of wmem_tree don't actually need the predecessor lookup it provides (the lookup_le function family). A hash map provides straight insertion and lookup much more efficiently than a wmem_tree when predecessor lookup isn't needed. - Many current users of glib's hash table and hash functions use untrusted data for keys, making them vulnerable to algorithmic complexity attacks. Care has been taken to make this implementation secure against such attacks, so it should be used whenever data is untrusted. In my benchmarks it is measurably slower than GHashTable, but not excessively so. Given the additional security it provides this seems like a reasonable trade-off (and it is still faster than a wmem_tree). Change-Id: I2d67a0d06029f14c153eaa42d5cfc774aefd9918 Reviewed-on: https://code.wireshark.org/review/1272 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-04-22Much faster implementation of 'strict' allocator.Evan Huus1-100/+72
Rather than using a hash table, which is overkill and slow, embed a doubly-linked-list in the prefix structure. On my tests with some random capture file and tshark -nxVr: - normal block allocator: ~2.1 seconds - old (slow) strict allocator: ~4.2 seconds - new (fast) strict allocator: ~2.8 seconds The buildbot will thank me :) Change-Id: I2fb42229c4ee4c40bbe45ba04b7848792998eaa9 Reviewed-on: https://code.wireshark.org/review/1251 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-04-15Fix warning when build with -WdocumentationAlexis La Goutte1-4/+4
epan/wmem/wmem_strutl.h:85:63: error: parameter 'str' is already documented [-Werror,-Wdocumentation] epan/wmem/wmem_strutl.h:85:27: note: previous documentation epan/wmem/wmem_strutl.h:90:39: error: parameter 'str' is already documented [-Werror,-Wdocumentation] epan/wmem/wmem_strutl.h:85:57: note: previous documentation epan/wmem/wmem_strutl.h:83:11: error: parameter 'allocator:' not found in the function declaration epan/wmem/wmem_strutl.h:83:11: note: did you mean 'allocator'? epan/wmem/wmem_strutl.h:84:11: error: parameter 'str:' not found in the function declaration [-Werror,-Wdocumentation] epan/wmem/wmem_strutl.h:85:11: error: parameter 'len:' not found in the function declaration [-Werror,-Wdocumentation] epan/wmem/wmem_strutl.h:85:11: note: did you mean 'len'? Change-Id: Id2888c5967c94c48f9b53957c8be361bbebd3488 Reviewed-on: https://code.wireshark.org/review/1151 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-04-14Fix warning when generate documentation (doxygen)Alexis La Goutte1-4/+4
epan/wmem/wmem_strutl.h:82: warning: Found unknown command `\allocator' epan/wmem/wmem_strutl.h:82: warning: Found unknown command `\allocator' epan/wmem/wmem_strutl.h:80: warning: Found unknown command `\str' epan/wmem/wmem_strutl.h:81: warning: Found unknown command `\len' epan/wmem/wmem_strutl.h:81: warning: Found unknown command `\str' epan/wmem/wmem_strutl.h:81: warning: Found unknown command `\st Change-Id: I0c3908f0e4aa84cc20fad954638b0cb10b1d6dee Reviewed-on: https://code.wireshark.org/review/1131 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-04-14Fix warning when generate documentation (doxygen)Alexis La Goutte1-1/+1
wireshark/epan/wmem/wmem_stack.h:39: Warning: group wmem-stack: ignoring title "Stack-bbab" that does not match old title "Queue" Change-Id: I9376651d89d9df21aeca82ddb952c230d546169a Reviewed-on: https://code.wireshark.org/review/1130 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-04-12Fix non-standard format specifiersEvan Huus1-1/+1
C90 permits plain %f for doubles. Thanks to Alexis for pointing this out. Change-Id: I3f927b0a50e5764c2297c7f9d680c6363ba9fd0e Reviewed-on: https://code.wireshark.org/review/1073 Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com> Reviewed-by: Michael Mann <mmann78@netscape.net>
2014-04-02Scrap wmem splay trees for now.Evan Huus5-718/+0
There is confusion about API usage, and problems on my part concerning whether keys should be compared signed or unsigned, and how to do that efficiently. Unsigned keys in particular were behaving oddly. Change-Id: I075693bbd04c15f79f24f9a24006003a914cc572 Reviewed-on: https://code.wireshark.org/review/924 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-03-31Continue to remove $Id$ from top of fileAlexis La Goutte3-5/+0
(Using sed : sed -i '/^\# \$Id\$/,+1 d') (start with dash) Change-Id: Ia4b5a6c2302f6a531f6a86c1ec3a2f8205c8c2dd Reviewed-on: https://code.wireshark.org/review/881 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-03-31Doc tweaks and macro parameterizationEvan Huus2-62/+73
Change-Id: I9898bedf05a785683e79866a149336cbbf402d27 Reviewed-on: https://code.wireshark.org/review/892 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-03-31Inlining wmem_strbuf_grow seems to give better performance.AndersBroman1-1/+1
Change-Id: I80f3d42fb01461af97984b463a6e8b8217eed552 Reviewed-on: https://code.wireshark.org/review/888 Reviewed-by: Evan Huus <eapache@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-03-29Splay tree implementation for wmemEvan Huus5-1/+710
This is a tree implementation intended to replace the current red-black tree in wmem_tree (which was inherited from emem), assuming there are no regressions. Splay trees bubble recently accessed keys to the top, and as such have a number of very nice properties: https://en.wikipedia.org/wiki/Splay_tree This implementation is a variant known as "independent semi-splaying", which has better practical performance. It should do about as well as the red-black tree for random insertions and accesses, but somewhat better for patterned accesses (such as accessing each key in order, or accessing certain keys very frequently). There are a few other changes relative to the red-black tree implementation that are worth mentioning: - Instead of requiring complex keys to be split into guint32 chunks and doing this weird trick with sub-trees, I let the keys be arbitrary pointers and allowed the user to specify an arbitrary comparison function. If the function is NULL then the pointers are compared directly for the simple integer-key case. - Splay trees do not need to store a red-black colour flag for each node. It is also much easier to do without the parent pointer in each node. And due to the simpler system for complex keys, I was able to remove the "is_subtree" boolean. As such, splay nodes are 12 bytes smaller on 32-bit platforms, and 16 bytes smaller on a 64-bit platform. All done in about half the lines of code. Change-Id: I89fb57e07d2bb7e3197190c7c2597b0c5adcc03b Reviewed-on: https://code.wireshark.org/review/758 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-03-29Implement finalize() method for wmem strbuf.Evan Huus3-0/+30
Change-Id: Ib7a2b0d348b3624f41253e2d0995a4a38a9fe45d Reviewed-on: https://code.wireshark.org/review/859 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-03-25Introduce wmem_ascii_strdown()AndersBroman3-0/+44
Change-Id: Icdc5a0d5033f3ab709fbf19a33ab26f609d4b1f0 Reviewed-on: https://code.wireshark.org/review/824 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-03-04Fix memory-alignment in the block allocator.Evan Huus1-2/+2
The previous macro gave the correct alignment, but there was one case where it would add a whole block of unnecessary ALIGN_SIZE bytes. The new one is also slightly faster to compute. Benchmark win of about 3%. Change-Id: I5d8bad0f78dc0e383e14c2c7a951328a06400020 Reviewed-on: https://code.wireshark.org/review/492 Reviewed-by: Evan Huus <eapache@gmail.com>
2014-03-04Remove all $Id$ from top of fileAlexis La Goutte31-62/+0
(Using sed : sed -i '/^ \* \$Id\$/,+1 d') Fix manually some typo (in export_object_dicom.c and crc16-plain.c) Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8 Reviewed-on: https://code.wireshark.org/review/497 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-03-04Remove assertions from block allocator.Evan Huus1-30/+0
It has been extremely well-tested at this point, and is a very hot code path so the performance gain is measurable (~1-2% on most captures I tried). Change-Id: I2f5e03d2f348f56e740bf0dfbc83a4fd9cc8c5a9 Reviewed-on: https://code.wireshark.org/review/499 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-01-05From Jim Young via https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9613Evan Huus1-3/+3
Don't use "rand" as a variable name, it shadows a global in recent MacOSX stdlib.h svn path=/trunk/; revision=54598
2013-12-24Add wmem_destroy_list, wmem_destroy_queue, wmem_destroy_stack so that thoseEvan Huus5-0/+35
data-structures can be used with manually managed memory. svn path=/trunk/; revision=54432
2013-12-20Try to please the buildbot.Anders Broman1-1/+1
svn path=/trunk/; revision=54281
2013-12-20Fix [-Wmissing-prototypes]Anders Broman5-3/+6
svn path=/trunk/; revision=54280
2013-12-15Fix some const/ not const warnings.Jakub Zawadzki1-2/+2
svn path=/trunk/; revision=54114
2013-11-05Expose wmem_list_remove_frame to make it efficient to do pop operations asEvan Huus2-0/+10
wmem_list_remove_frame(wmem_list_tail()) svn path=/trunk/; revision=53088
2013-10-19Don't link explicitly with libwmem, it's already in libwireshark and the symbolEvan Huus1-2/+2
doubling leads to all sorts of very subtle badness (including test failures due to funny internal assertions because the two wmems have mismatching state). Make wmem_init and wmem_cleanup PUBLIC instead of LOCAL so that they don't get stripped and don't cause a link failure when trying to build oids_test (now that it's not linking with libwmem explicitly). There is possibly a better way to fix this, but I'm not sure what it is. svn path=/trunk/; revision=52694
2013-10-15As suggested separately by both Jakub and Anders: only read theEvan Huus2-55/+39
WIRESHARK_DEBUG_WMEM_OVERRIDE environment variable once in wmem_init, not every time wmem_allocator_new is called. We currently create a new pinfo pool for every packet we dissect, so this is a small performance win, especially when getenv is slow (which may happen if a large number of environment variables are set, such as when fuzz-testing). svn path=/trunk/; revision=52634
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-27 09:09:06 +0000