Remove use of -H:-ParseOnce in GraalVM 22.2

[galderz]

When ParseOnce was first introduced, we discovered that the overall memory consumption went up. In my most recent testing with 22.1, ParseOnce still added extra memory, but during the Native Image Committer Community Meeting 2022-06-02 meeting Christian mentioned that memory improvements have gone in 22.2 which should solve the problem of extra memory usage.

I will carry out tests with 22.2 to verify this.

[jerboaa]

Related mandrel issue: graalvm/mandrel#316

[zakkak]

Quote from #25943 (comment)

Re: ParseOnce. At the end of June I carried some tests to verify its effects on 22.2 and indeed the memory usage had improved, so it no longer resulted in a max RSS penalty. So I think it's safe to remove disabling it.

I performed some more extensive testing which shows that this is still not always true. What seems to hold though is that -H:+ParseOnce no longer results in requiring more than 8GB of memory which was causing issues in github actions, so we could disable it and leave the option of using -H:-ParseOnce or not to the users. WDYT?

[galderz]

@zakkak Thanks for the exhaustive testing. It's important not to forget that there's some variability in the native build memory usage. In my local testing I've found that memory usage varies between different runs with the same configuration. E.g. for the Hibernate ORM quickstart:

• With ParseOnce disabled, max RSS can be as low as 6.5GB and as high as 8.1GB, that's a 24% difference between the lowest and the highest.
• With ParseOnce enabled, max RSS can be as low as 6.7GB and as high as 8.1GB, with a difference of 20%.

What I'm trying to say with this is that your ranges of -12% and +19% fall within the variability I see above. So, which ones take more or less max RSS might not be ParseOnce related.

[galderz]

Note that in my testing I don't pass in -Xmx into the native image build processes, so that's why the max RSS numbers can look higher than the ones found in the testsuite runs.

[zakkak]

What I'm trying to say with this is that your ranges of -12% and +19% fall within the variability I see above. So, which ones take more or less max RSS might not be ParseOnce related.

True, my comparison is not that solid, but the fact that I am reproducing more or less the same results (in terms of RSS usage increase) with the last two times I ran similar tests (a couple of releases before 22.2) make me feel confident about this numbers.

In any case, I am OK with enabling ParseOnce (given that the CI is now happy with it) and letting the users disable it on demand if they really need to. Please see #27462

[galderz]

In any case, I am OK with enabling ParseOnce (given that the CI is now happy with it) and letting the users disable it on demand if they really need to. Please see #27462

That sounds good. Having an option to disable it in case it becomes a problem would be a good escape hatch if someone encounters memory issues with this.

[jerboaa]

In any case, I am OK with enabling ParseOnce (given that the CI is now happy with it) and letting the users disable it on demand if they really need to. Please see #27462

That sounds good. Having an option to disable it in case it becomes a problem would be a good escape hatch if someone encounters memory issues with this.

Wouldn't that be covered by passing -Dquarkus.native.additional-build-args="-H:-ParseOnce"?

[galderz]

@jerboaa Yes it is, I realised that after posting the comment.