RFR: 8263460: DynamicArchiveRelocationTest.java fails in product VM [v2]

[Ioi Lam]

On Fri, 12 Mar 2021 07:46:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The special handling for Windows is not needed anymore?

Hi Thomas, thanks for looking into this.

You're correct that the Windows port may work differently. When mapping to the requested address, some of the regions may fail to map due to ASLR, so you are not guaranteed to have two "Unmapping region ..." messages.

Also, this is theoretically not limited to Windows, either. Some other OS ports may also make the requested address unavailable due to ASLR.

Therefore, I decided to get rid of the pattern matching altogether. We know that the native code will try its best to exercise the mapping and unmapping code, so as long as the program exits normally, we know all has gone well :-)


> I have the feeling this could be made simpler in general (not in this fix). E.g. instead of mapping, then unmapping, which causes the execution paths between non-product and product to be quite different, why not just reserve a "rogue" allocation in the middle of the soon-to-map region? Would that not be a more reliable and realistic test?
> 
> Cheers, Thomas

Such a "rouge" region would need to be allocated inside the VM code, since we can't easily do it from the "driver" process of the test, Also, this will cause at least one of the regions to fail to map. As a result, we cannot test the case where all the regions are mapped, but then we have to unmap them due to other reasons.

Admittedly, a different way to test this is to corrupt the CRC of one of the regions. This should be done in appcds/SharedArchiveConsistency.java but we exit the VM and don't exercise the code for unmapping. I have created [JDK-8263538](https://bugs.openjdk.java.net/browse/JDK-8263538) (SharedArchiveConsistency.java should test -Xshare:auto as well)

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

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