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

Skip to content

Conversation

@cherusker
Copy link
Contributor

As the Unlocked* () functions have been approved in #5310, I used them to blacklist some of the most obvious counting variables whose data races should be ignored: MonoStats, GCStats and JITGCStats (more to follow if approved).

Please find details about all changes within the commit messages.

@dnfclas
Copy link

dnfclas commented Aug 15, 2017

@cherusker,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

Copy link
Member

Choose a reason for hiding this comment

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

@BrzVlad is the size arg of sgen_client_degraded_allocation not useful?

Copy link
Contributor

Choose a reason for hiding this comment

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

Anything starting with sgen_client_ is part of the SGen API, so this is a breaking change.

Copy link
Member

Choose a reason for hiding this comment

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

@alexrp I don't think these are meant to be an official API and they were changed in the past. Are there other runtimes out there that actually use sgen in the first place ?

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess @schani would know. He did the whole SGen separation effort for a use case I can't remember.

Copy link
Contributor

Choose a reason for hiding this comment

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

Changing this is fine.

Copy link
Contributor

Choose a reason for hiding this comment

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

Please split the changes to this file into a separate commit.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@alexrp sure; done!

@cherusker cherusker force-pushed the cherusker-2017-08-15-spread-unlocked branch from 4e37630 to 435c428 Compare August 15, 2017 22:32
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@luhenry can we compare with == GENERATION_NURSERY here?

Copy link
Contributor

Choose a reason for hiding this comment

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

yes you can. also, you can use Interlocked here.

@vargaz
Copy link
Contributor

vargaz commented Aug 15, 2017

A lot of the counters are in somewhat perf sensitive code, you don't want an atomic operation every time an object etc. is created for example. The ones in the JIT are ok.

@cherusker
Copy link
Contributor Author

@vargaz the Unlocked* () functions have absolutely no performance impact (if compiled without the TSan setup); if, however, the affected JIT functions are not as performance critical as the rest - should we / can we use the Interlocked* () functions there instead of the Unlocked* () ones?

@vargaz
Copy link
Contributor

vargaz commented Aug 15, 2017

The non-perf critical ones can use the simple Interlocked functions.

Copy link
Contributor

@lewurm lewurm left a comment

Choose a reason for hiding this comment

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

I annotated all sites that I think aren't performance critical and thus can use Interlocked. In general, I think most of the stuff in your PR isn't perf-critical, except the JIT info lookup and IMT machinery. @vargaz can you have a look again and check if my assessment is correct?

Copy link
Contributor

Choose a reason for hiding this comment

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

can be Interlocked

Copy link
Contributor

Choose a reason for hiding this comment

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

can be Interlocked

Copy link
Contributor Author

@cherusker cherusker Aug 18, 2017

Choose a reason for hiding this comment

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

@vargaz @lewurm can I convert the gc_stats.*_gc_time_* values (gc-internal-agnostic.h) to gint64? The reason behind this: An InterlockedAdd64 () function exists already, however, I would have to "invent" InterlockedAddUnsigned64 (). Furthermore, @vargaz told me to simply use signed types if there is no explicit reason for using unsigned ones (#5299) and 9,223,372,036,854,775,807 ns are still almost 300 years ... do we really need 600 years?

Copy link
Contributor

Choose a reason for hiding this comment

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

should be fine. also, mono_100ns_ticks () returns a gint64.

Copy link
Contributor

Choose a reason for hiding this comment

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

can be Interlocked

Copy link
Contributor

Choose a reason for hiding this comment

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

everything can use Interlocked here

Copy link
Contributor

Choose a reason for hiding this comment

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

can be Interlocked

Copy link
Contributor

Choose a reason for hiding this comment

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

can be Interlocked

Copy link
Contributor

Choose a reason for hiding this comment

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

can be Interlocked

Copy link
Contributor

Choose a reason for hiding this comment

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

can be Interlocked

Copy link
Contributor

Choose a reason for hiding this comment

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

can be Interlocked

Copy link
Contributor

Choose a reason for hiding this comment

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

yes you can. also, you can use Interlocked here.

- add functions for upcoming commits
- add `InterlockedWriteBool ()` which will be used in an upcoming commit
- change field types from `size_t` to `gint32`
  - GLib types are preferably used throughout Mono
  - `Interlocked* ()` functions exist for `gint32` already
  - `gint32` is preferred to `gint64` when looking at 32-bit machines
  - the extra 2,147,483,648 (0 <= `size_t` <= 4,294,967,295; -2,147,483,648 <= `gint32` <= 2,147,483,647) don't seem to matter when looking at the average values of these variables
- remove unused fields; some fields have been moved to GCStats (`*_gc_*`)
- use `G_*_FORMAT` to correctly print `g*` types
- `minor_gc_count` and `major_gc_count`: use `gint32` as the `binary_protocol_collection* ()` and `sgen_debug_dump_heap ()` functions cast these values to `int` anyways
- `*_gc_time_*`: use `gint64` since 300 years seem like a fair amount of time and `Interlocked*64 ()` can be used
- adjust the logic of `sgen_gc_collection_count ()` to enhance its readability
- parameter `size` of `sgen_client_degraded_allocation` is unused and can be removed
- use `Interlocked* ()` for static variables of `sgen_client_degraded_allocation ()`
- use `G_*_FORMAT` to correctly print `g*` types
- change the field types from `int` to `gint32`
@cherusker cherusker force-pushed the cherusker-2017-08-15-spread-unlocked branch from 435c428 to 441a6f6 Compare August 18, 2017 19:39
/* The following functions cannot be found on any platform, and thus they can be declared without further existence checks */

static inline void
InterlockedWriteBool (volatile gboolean *dest, gboolean val)
Copy link
Contributor Author

@cherusker cherusker Aug 18, 2017

Choose a reason for hiding this comment

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

@BrzVlad @alexrp is it OK to put this function there?

@cherusker
Copy link
Contributor Author

The most recent update changed a lot of functions from Unlocked* () to Interlocked* () and also changed the types of MonoStats variables from gsize to gint32. The reason for that is explained in the commit message: mainly it's about Interlocked* () being defined for gint32 but not for gsize. If this is unwanted, however, I can either

  • go back to gsize and add Interlocked*Size () methods to atomics.h or
  • we can go with gint64.

@vargaz
Copy link
Contributor

vargaz commented Aug 18, 2017

I think we should use either gint32 or gint64, depending on the expected values.

@cherusker
Copy link
Contributor Author

@vargaz I have seen these values going into the low millions but always staying far away from the billions with class_vtable_size usually leading. After all, I only reduced the capacity by the factor 2 (no log reduction or worse) - so generally it should not matter. Anyways, gint64 would be safer of course if it's OK to use it for performance-critical code thinking about the overhead of 64-bit operations on 32-bit machines JUST for monitoring. @kumpera do you have any thoughts on this?

@vargaz
Copy link
Contributor

vargaz commented Aug 18, 2017

I think gint64 is only needed for things like amount of GC memory allocated.

@lewurm
Copy link
Contributor

lewurm commented Aug 23, 2017

@monojenkins squash

@monojenkins monojenkins merged commit 787faec into mono:master Aug 23, 2017
@cherusker cherusker deleted the cherusker-2017-08-15-spread-unlocked branch August 23, 2017 17:58
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
[TSan] Unlocking MonoStats, GCStats and JITGCStats

As the `Unlocked* ()` functions have been approved in mono/mono#5310, I used them to blacklist some of the most obvious counting variables whose data races should be ignored: `MonoStats`, `GCStats` and `JITGCStats` (more to follow if approved).

Please find details about all changes within the commit messages.


Commit migrated from mono/mono@787faec
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants