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

Thomas Stuefe stuefe at openjdk.java.net
Wed Feb 24 12:46:40 UTC 2021


On Wed, 24 Feb 2021 12:08:36 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 104:
>> 
>>> 102:     private static void parseSmaps() throws Exception {
>>> 103:         Pattern smapsPattern = Pattern.compile(RangeWithPageSize.smapsPatternString, Pattern.DOTALL);
>>> 104:         Scanner smapsScanner = new Scanner(new File("/proc/self/smaps"));
>> 
>> Would that work if mappings are concurrently modified? (I guess it has to otherwise one could not read reliably from /proc at all)
>
> 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.

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

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


More information about the hotspot-runtime-dev mailing list