RFR: 8262188: Add test to verify trace page sizes logging on Linux

[Stefan Johansson]

On Wed, 24 Feb 2021 12:40:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I can't say for sure, not sure exactly how the file is consumed by the Scanner. The segments and the fields in those segments that we really care about should not change and therefore I think we should be fine.
>
> I looked at https://www.kernel.org/doc/Documentation/filesystems/proc.txt
> Note: reading /proc/PID/maps or /proc/PID/smaps is inherently racy (consistent
> output can be achieved only in the single read call).
> This typically manifests when doing partial reads of these files while the
> memory map is being modified.  Despite the races, we do provide the following
> guarantees:
> 
> 1) The mapped addresses never go backwards, which implies no two
>    regions will ever overlap.
> 2) If there is something at a given vaddr during the entirety of the
>    life of the smaps/maps walk, there will be some output for it.
> 
> So, if Scanner reads the file in one go its okay. 
> 
> I'd say lets see how this goes then. If this test fails intermittently, we know where to look.

I did a very basic test in `jshell` and created a `Scanner` on a file that I then updated between calls to `nextLine()`. The output from the scanner did not include my additions, so at least for a small file is seems like the contents is read in one go. But that doesn't say that is always the case. 

Bu I agree, we know where to look if we see intermittent failures.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2696