It is discovered that some fuzzer runs into OutOfMemoryError because of GC overhead limit exceeded. JDK garbage collection (GC) will try to free up memory when some unused object is found. If there is too much repeating instance creation and dropped, the GC will take up high working load. When the working load is higher than the preset overhead of the JVM (normally set to 98%), an OutOfMemoryError is thrown. Some of the fuzzers of keycloak create a new set of mock object in every iteration. It means that it will build up a high amount of "garbage" for the GC to work with. This eventually reach the GC overhead limit. This PR fixes one of the fuzzer to try moving the mock object creation in the fuzzerInitialize method (which only execute once when the fuzzer start and will not execute per iteration) and only randomize the mock return of these object in each iteration to decrease the GC work overhead.
It is discovered that some fuzzer runs into OutOfMemoryError because of GC overhead limit exceeded. JDK garbage collection (GC) will try to free up memory when some unused object is found. If there is too much repeating instance creation and dropped, the GC will take up high working load. When the working load is higher than the preset overhead of the JVM (normally set to 98%), an OutOfMemoryError is thrown. Some of the fuzzers of keycloak create a new set of mock object in every iteration. It means that it will build up a high amount of "garbage" for the GC to work with. This eventually reach the GC overhead limit. This PR fixes one of the fuzzer to try moving the mock object creation in the fuzzerInitialize method (which only execute once when the fuzzer start and will not execute per iteration) and only randomize the mock return of these object in each iteration to decrease the GC work overhead.