Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8291893

riscv: remove fence.i used in user space

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Fixed
    • P4
    • 20
    • 19
    • hotspot
    • None
    • b10
    • riscv
    • linux

    Backports

      Description

        The usage of fence.i is in-efficient or redundant in the current implementation of riscv port now. The riscv port has already followed the [RISC-V platform specification](https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc): the write hart use the __builtin__clear_cache or the syscall riscv_flush_icache directly after modifying code in riscv port, to execute fence.i on local hart and other harts by IPI. That's because fence.i only synchronizes the local hart, and the OS can reschedule the user hart to a different physical hart after the fence.i.

        "To order older stores before younger instruction fetches, user-level programs must use system supplied
        library calls (e.g. GNU libc's __riscv_flush_icache, which invokes the Linux kernel's
        corresponding vDSO routine), rather than executing the fence.i instruction directly."

        What now seems unnecessary is that we also put fence.i in front of code that will be modifed concurrently, just like Aarch64 port. Because the icache flush syscall already provides the explicit icache synchronization between all harts, so that we can remove fence.i used in the read hart.
        Details of the discussion can be found in https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000571.html.

        In contrast, the isb in aarch64 is not broadcast by the writing PE, so any other PE must perform its own isb synchronization after it knows that the instruction update is visible.

        Attachments

          Issue Links

            Activity

              People

                yadongwang Yadong Wang
                yadongwang Yadong Wang
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: