pthread_jit_write_protect_np(0) crashes if com.apple.security.cs.allow-jit isn't enabled on Mac (aarch64) (with a zero-variant JDK)

[Tanin Na Nakorn]

Is there a plan to make the zero variant to comply with the no JIT
definition from Apple? Or is it a no-go since JVM may depend heavily on
this mechanism? (I'm unfamiliar with the area and would like to understand
a bit more.)

> Sure, just wrap the call in #ifndef ZERO.

I tried commenting it out completely. It failed on being unable to reserve
code cache. The mechanism seems to be essential.

> That sounds right. Even with no compiler, AArch64 HotSpot still will
generate an interpreter, and that's effectively JIT as far as Apple is
concerned.

Thank you so much. This insight is helpful.


On Mon, Oct 6, 2025 at 10:55 AM Andrew Haley <aph-open at littlepinkcloud.com>
wrote:

> On 06/10/2025 18:30, Tanin Na Nakorn wrote:
> > 1. Does this mean a sandboxed Java app on Mac will always require
> > com.apple.security.cs.allow-jit?
>
> No, it just means that no one tried it.
>
> > Is there a way around this? For
> > example, is there a way to avoid using pthread_jit_write_protect_np(0)
> > in the zero variant?
>
> Sure, just wrap the call in #ifndef ZERO.
>
> > 2. It seems like the term JIT has different meanings for Java and Apple
> > where, for Java, it means not to use compiler1 and compiler 2. But, for
> > Mac, it means something else e.g. never use
> > pthread_jit_write_protect_np(0) and generate code.
>
> That sounds right. Even with no compiler, AArch64 HotSpot still will
> generate an interpreter, and that's effectively JIT as far as Apple is
> concerned.
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20251006/fab23c30/attachment-0001.htm>