Thanks to visit codestin.com
Credit goes to github.com

Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions mono/metadata/mempool.c
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,7 @@

#include "mempool.h"
#include "mempool-internals.h"
#include "utils/mono-compiler.h"

/*
* MonoMemPool is for fast allocation of memory. We free
Expand Down Expand Up @@ -92,9 +93,19 @@ mono_mempool_new (void)

/**
* mono_mempool_new_size:
*
* clang's ThreadSanitizer detects races of total_bytes_allocated and pool->d.allocated throughout the functions
* * mono_mempool_alloc
* * mono_mempool_new_size
* * mono_mempool_destroy
* while these races could lead to wrong values, total_bytes_allocated is just used for debugging / reporting and since
* the mempool.c functions are called quite often, a discussion led the the conclusion of ignoring these races:
* https://bugzilla.xamarin.com/show_bug.cgi?id=57936
*
* \param initial_size the amount of memory to initially reserve for the memory pool.
* \returns a new memory pool with a specific initial memory reservation.
*/
MONO_NO_SANITIZE_THREAD
MonoMemPool *
mono_mempool_new_size (int initial_size)
{
Expand All @@ -120,10 +131,20 @@ mono_mempool_new_size (int initial_size)

/**
* mono_mempool_destroy:
*
* clang's ThreadSanitizer detects races of total_bytes_allocated and pool->d.allocated throughout the functions
* * mono_mempool_alloc
* * mono_mempool_new_size
* * mono_mempool_destroy
* while these races could lead to wrong values, total_bytes_allocated is just used for debugging / reporting and since
* the mempool.c functions are called quite often, a discussion led the the conclusion of ignoring these races:
* https://bugzilla.xamarin.com/show_bug.cgi?id=57936
*
* \param pool the memory pool to destroy
*
* Free all memory associated with this pool.
*/
MONO_NO_SANITIZE_THREAD
void
mono_mempool_destroy (MonoMemPool *pool)
{
Expand Down Expand Up @@ -251,13 +272,23 @@ get_next_size (MonoMemPool *pool, int size)

/**
* mono_mempool_alloc:
*
* clang's ThreadSanitizer detects races of total_bytes_allocated and pool->d.allocated throughout the functions
* * mono_mempool_alloc
* * mono_mempool_new_size
* * mono_mempool_destroy
* while these races could lead to wrong values, total_bytes_allocated is just used for debugging / reporting and since
* the mempool.c functions are called quite often, a discussion led the the conclusion of ignoring these races:
* https://bugzilla.xamarin.com/show_bug.cgi?id=57936
*
* \param pool the memory pool to use
* \param size size of the memory block
*
* Allocates a new block of memory in \p pool .
*
* \returns the address of a newly allocated memory block.
*/
MONO_NO_SANITIZE_THREAD
gpointer
mono_mempool_alloc (MonoMemPool *pool, guint size)
{
Expand Down
11 changes: 11 additions & 0 deletions mono/utils/mono-compiler.h
Original file line number Diff line number Diff line change
Expand Up @@ -113,5 +113,16 @@ typedef SSIZE_T ssize_t;
#define MONO_GNUC_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__)
#endif

/* Used to tell clang's ThreadSanitizer to not report data races that occur within a certain function */
#if defined(__has_feature)
Copy link
Contributor

@alexrp alexrp Jul 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we factor this into a separate macro? Like so:

#if defined (__has_feature)
#define MONO_CLANG_HAS_FEATURE (...) (__has_feature (__VA_ARGS__))
#else
#define MONO_CLANG_HAS_FEATURE (...) (FALSE)
#endif

#if MONO_CLANG_HAS_FEATURE (thread_sanitizer)
#define MONO_NO_SANITIZE_THREAD __attribute__ ((no_sanitize ("thread")))
#else
#define MONO_NO_SANITIZE_THREAD
#endif

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer having a simple macro, not a magic one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vargaz are you for or against @alexrp's idea? Generally non of the two versions look too magical to me - the current one is more compact (IMO), the idea of @alexrp has a better reusability which will come handy when working with other clang features in the future - generally I'm tempted to use what @alexrp suggested :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the simple version.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest to leave it as it is for this PR but definitely think about expanding the macro, once more checkers are added that rely on __has_feature.

#if __has_feature(thread_sanitizer)
#define MONO_NO_SANITIZE_THREAD __attribute__ ((no_sanitize("thread")))
#else
#define MONO_NO_SANITIZE_THREAD
#endif
#else
#define MONO_NO_SANITIZE_THREAD
#endif

#endif /* __UTILS_MONO_COMPILER_H__*/