diff options
| author | Noah Falk <noahfalk@users.noreply.github.com> | 2019-06-25 16:33:08 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-06-25 16:33:08 -0700 |
| commit | 74ccf988e52f083e24b5ac3bc0db0702588b2572 (patch) | |
| tree | dab555b45fc71c3762551e75d1b6643ab6c44981 | |
| parent | 3d7247e894cdc8d158ab3874b434de77e6418241 (diff) | |
| download | coreclr-74ccf988e52f083e24b5ac3bc0db0702588b2572.tar.gz coreclr-74ccf988e52f083e24b5ac3bc0db0702588b2572.tar.bz2 coreclr-74ccf988e52f083e24b5ac3bc0db0702588b2572.zip | |
Policheck comment adjustment
| -rw-r--r-- | src/vm/eventpipebuffermanager.cpp | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/vm/eventpipebuffermanager.cpp b/src/vm/eventpipebuffermanager.cpp index 3ac90fd719..af403ff168 100644 --- a/src/vm/eventpipebuffermanager.cpp +++ b/src/vm/eventpipebuffermanager.cpp @@ -576,7 +576,7 @@ void EventPipeBufferManager::WriteAllBuffersToFileV4(EventPipeFile *pFile, LARGE // in the current scheme. In the worst case you could imagine N threads, each of which was already allocated a // max size buffer (currently 1MB) but only an insignificant portion has been used. Even if the trigger // threshhold is a modest amount such as 10MB, the threads could first write 1MB * N bytes to the stream - // beforehand. I'm betting on these extreme cases being very rare and even something like 1GB isn't a crazy + // beforehand. I'm betting on these extreme cases being very rare and even something like 1GB isn't an unreasonable // amount of virtual memory to use on to parse an extreme trace. However if I am wrong we can control // both the allocation policy and the triggering instrumentation. Nothing requires us to give out 1MB buffers to // 1000 threads simulatneously, nor are we prevented from observing buffer usage at finer granularity than we |