RFR: 8267155: runtime/os/TestTracePageSizes times out [v4]

Stefan Johansson sjohanss at openjdk.java.net
Tue May 18 09:54:41 UTC 2021


On Tue, 18 May 2021 04:03:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > Cursory review follows.
> > The alternative would be to disable this on kernels < 3.8? See the commits from my last PR:
> > https://github.com/openjdk/jdk/pull/3415/files/c7a6136cedb827260f43ecc850a8910492cfefcc..1df37de73ed6615db565aeafe76edf30dcee108d
> 
> Hmm, I like faster tests even on new kernels, therefore I would like to use this parser instead of the regex. Also think it makes the test more readable and robust, but that may be just me. E.g. you don't rely on order of entry in smaps.
> 
> But we could do both, of course. Lets ask @kstefanj , its his test.

I'm of course biased since I wrote the test. That said, I don't consider this _my_ test, so I won't object to changing it. 

Personally I prefer the regex-parsing is clearer since it "parses" one segment at a time in the smaps file. I think if we go with this new parser, it would be nice to add some comments clarifying the steps. 

An alternative would be to have different regular expressions depending on the kernel version or first check if vmFlags are present and choose the correct expression. This would of course not help if this kind of parsing is still very slow on some systems.

I like that you do a copy of smaps before parsing, that crossed my mind as well, to help debugging. Regarding smaller heap sizes. I don't see a problem if some of the test VMs fail getting large pages, since it tests that we still log the correct thing. 

Just wanted to share my thoughts before doing a proper review. I'm happy to review this patch if we decide to go with this new parser. If we do that I also think we should look at enabling parsing of `AnonHugePages` for the case where vmFlags are not present (similar to @shipilev approach in the last PR).

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

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


More information about the hotspot-runtime-dev mailing list