RFR: 8290025: Remove the Sweeper

Erik Österlund eosterlund at openjdk.org
Thu Aug 4 12:41:54 UTC 2022


On Thu, 4 Aug 2022 12:14:40 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Hi Erik,
> 
> 
> 
> The change breaks the ARM32 port as the nmethod entry barriers are not implemented there yet. We need a way to work without nmethod entry barriers for the ARM32 platform.
> 
> 
> 
> ```
> 
> # To suppress the following error report, specify this argument
> 
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/barrierSetNMethod_arm.cpp:38
> 
> #
> 
> # A fatal error has been detected by the Java Runtime Environment:
> 
> #
> 
> #  Internal Error (/home/boris/jdk-fisk/src/hotspot/cpu/arm/gc/shared/barrierSetNMethod_arm.cpp:38), pid=10206, tid=10207
> 
> #  Error: ShouldNotReachHere()
> 
> #
> 
> # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.boris.jdk-fisk)
> 
> # Java VM: OpenJDK Server VM (fastdebug 20-internal-adhoc.boris.jdk-fisk, mixed mode, g1 gc, linux-arm)
> 
> # Problematic frame:
> 
> # V  [libjvm.so+0x2bd610]  BarrierSetNMethod::is_armed(nmethod*)+0x2c
> 
> ```

Is there a plan for the arm32 port to support nmethod entry barriers? I would really appreciate if the solution to this problem is that arm32 implements nmethod entry barriers. You only need to support the STW data and code patching variation, and it should do pretty much exactly what said AArch64 port does. Arm32 is the only platform I know of that doesn't support nmethod entry barriers, and IMO the JVM should be able to assume this is a feature that we can rely on.

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

PR: https://git.openjdk.org/jdk/pull/9741


More information about the hotspot-dev mailing list