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