mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Rukletsov <ruklet...@gmail.com>
Subject Re: Review Request 63368: Added MemoryProfiler class to Libprocess.
Date Mon, 12 Feb 2018 13:11:03 GMT


> On Feb. 6, 2018, 5:48 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/src/memory_profiler.cpp
> > Lines 243-249 (patched)
> > <https://reviews.apache.org/r/63368/diff/3/?file=1951296#file1951296line243>
> >
> >     I think it is safe to use this function because it is only accessed from `MemoryProfiler::DiskArtifact::path()`
which is in turn only accessed from `MemoryProfiler` methods, which are always serialized.
You should call this in a comment or even employ `process::Once` now to make sure it is thread-safe
and hence future-proof.
> 
> Benno Evers wrote:
>     I will add a comment. I think using `Once` can be counter-productive, because the
serialization provided by `libprocess` is fundamental enough that most likely everything would
break if it wouldn't exist - leading the reader to wonder why it isn't enough in this function
so that `Once` needs to be used.

The reason I suggested to use `Once` is because this is a free function and it is not immediately
clear that it is called only from a single actor instance.


> On Feb. 6, 2018, 5:48 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/src/memory_profiler.cpp
> > Lines 264 (patched)
> > <https://reviews.apache.org/r/63368/diff/3/?file=1951296#file1951296line264>
> >
> >     Say "using std::string" in the beginning of the file and save hundreds of characters!
> 
> Benno Evers wrote:
>     I'm not a fan of using `using`-directives just to save some typing, as it puts a
large cognitive burden on the reader: Is `string` referring to name imported to the global
namespace via `using`, a class-local or a function-local typedef, maybe defined in some `stout`-header?
In any case, one has to jump to a different context to double-check. Using `std::string`,
on the other hand, is not ambigous.

```
alex@alexr: ~/Projects/mesos $ grep -r -i --include *.cpp "std::string" ./src | wc -l    
 
     465

alex@alexr: ~/Projects/mesos $ grep -r -i --include *.cpp "using std::string" ./src | wc -l
     371
```
We have ~370 .cpp files with `using std::string` and \<100 mentions of `std::string`. We
also do not provide our own string type; ambiguous local typedefs shall not be used.

In addition to the above, I personally find meaningless prefixes and characters, like `std::`,
contributing to the cognitive load of the code.


> On Feb. 6, 2018, 5:48 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/src/memory_profiler.cpp
> > Lines 630 (patched)
> > <https://reviews.apache.org/r/63368/diff/3/?file=1951296#file1951296line630>
> >
> >     Use `profilingTimer->timeout().remaining()` directly.
> 
> Benno Evers wrote:
>     There are two issues with that:
>     1) The redirectTime is currently selected to be 2 seconds shorter than the time remaining
in the profiling timer, so by default it is the redirect that is stopping the profiling
>     2) Aesthetically, if a user is selecting `duration=5secs` it seems odd to display
`You will be redirected in 4.99993 seconds`.

Re 2): You will have this case anyway if profiling is in progress when the request arrives;
you can also round it up.

Re 1): I'm not sure I understand why you use this 2s delay.


- Alexander


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/63368/#review196894
-----------------------------------------------------------


On Feb. 6, 2018, 5:45 p.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63368/
> -----------------------------------------------------------
> 
> (Updated Feb. 6, 2018, 5:45 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov and Benjamin Mahler.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This class exposes profiling functionality of jemalloc memory allocator
> when it is detected to be the memory allocator of the current process.
> 
> In particular, it gives developers an easy method to collect and
> access heap profiles which report which pieces of code were
> responsible for allocating memory.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/Makefile.am 3071b7ce2b82a4ce0ea62e4d2b3518a6f5114803 
>   3rdparty/libprocess/include/process/memory_profiler.hpp PRE-CREATION 
>   3rdparty/libprocess/include/process/process.hpp 8661706cb058efb26f5bfbcc84972f9930d3670f

>   3rdparty/libprocess/src/CMakeLists.txt f002c157dc2ca64da66bc4e61f5095f2b533ae1f 
>   3rdparty/libprocess/src/memory_profiler.cpp PRE-CREATION 
>   3rdparty/libprocess/src/process.cpp ba9bc291bb6741e32b3a066fe90771311d21852a 
> 
> 
> Diff: https://reviews.apache.org/r/63368/diff/4/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Benno Evers
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message