Adar Dembo has posted comments on this change. Change subject: WIP: KUDU-1992. striped64: don't heap-allocate the threadlocal hashcode ......................................................................
Patch Set 1: (2 comments) http://gerrit.cloudera.org:8080/#/c/6791/1//COMMIT_MSG Commit Message: PS1, Line 24: This fix seemed simpler than trying to ensure some specific ordering of : threadlocal destructors (eg by assigning destructor priorities or adding : some kind of dependency graph). This is reasonable. I went looking for other instances of class-scoped static thread locals (i.e. the macros from threadlocal.h). The only one I found was the KernelStackWatchdog's state. AFAICT, the only way it could trigger a similar bug is if an item cached in the ThreadLocalCache invoked SCOPED_WATCH_STACK() when being destructed. At the moment: 1. The only ThreadLocalCache use is for BloomCacheItem, which doesn't do that. 2. I'm hard-pressed to think of a case where such a thing would _ever_ happen. It would mean that the cached item's destructor call graph somehow performed an operation that was expected to block on I/O for some time. I suppose if the call graph included a deref of a shared object whose destructor did IO, such as LBM's LogBlock, but even in that case the IO is thunked to a different thread. http://gerrit.cloudera.org:8080/#/c/6791/1/src/kudu/util/striped64.cc File src/kudu/util/striped64.cc: PS1, Line 57: // Avoid zero to allow xorShift rehash Now we're also avoiding zero because it's a magic value that indicates that we need to generate the hash code. -- To view, visit http://gerrit.cloudera.org:8080/6791 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I2d4e5264134c70ced434c3ae8da5866a151464d5 Gerrit-PatchSet: 1 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Todd Lipcon <[email protected]> Gerrit-Reviewer: Adar Dembo <[email protected]> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Tidy Bot Gerrit-HasComments: Yes
