Does this render https://hibernate.atlassian.net/browse/HV-633#icft=HV-633 obsolete?

I think so. Resolving it.

Does this render https://hibernate.atlassian.net/browse/HV-633#icft=HV-633 obsolete?

The test tries to force a GC cleanup by pushing the PermGen to its limit. But PermGen was removed in JDK 8. So under JDK 8, this test will just keep going, expanding the memory dynamically based on the native memory available.

Interesting. The intention of the test was not to exceed the PermGen, but indeed it might have done so as a side effect due to the ClassLoader and Class creation.
The intention was to exceed the heap. We might just be able to remedy this by allocating some heap as we go along - https://github.com/hferentschik/hibernate-validator/commit/a5de7218fd303bf4266e57a0b15b3fbe9f1616c9

One thing we can do is use the new flag MaxMetaspaceSize to limit the available memory. I tried -XX:MaxMetaspaceSize=128m and the test took about 21s.

But you would need to set that as JVM option at startup or at least for the thread running the test. If possible I find it preferable to just allocate heap space.

The test tries to force a GC cleanup by pushing the PermGen to its limit. But PermGen was removed in JDK 8. So under JDK 8, this test will just keep going, expanding the memory dynamically based on the native memory available.

One thing we can do is use the new flag MaxMetaspaceSize to limit the available memory. I tried -XX:MaxMetaspaceSize=128m and the test took about 21s.