Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[C-Ext] Fix patchable jals spanning cache lines #24

Open
wants to merge 3 commits into
base: riscv-port-branch
Choose a base branch
from

Conversation

zhengxiaolinX
Copy link
Collaborator

@zhengxiaolinX zhengxiaolinX commented Oct 15, 2021

Hi team,

This patch includes several fixes for the C extension support. It contains three small patches to fix different problems or potential issues.

  1. As @yadongw has suggested, MacroAssembler::far_call() has a reserved place needing a fix. Though hardly reachable, for its correctness we also need to fix it.
  2. After supporting the C extension, instructions become 2-byte aligned - also for trampolines. In order to make the emit_int64((intptr_t)dest) 8-byte aligned, some code needs a revise to adjust the new change. We have checked places where unalignment-related issues could occur and found this one, and now the 64-bit addresses in trampolines are properly aligned.
  3. The third issue is a crash which is a bit hard to address, only happening by using the C extension.
    Please see a hs_err file attached.
    In short, patchable instructions' patching bits must not span cache lines. Concisely, the problem is that, after the C extension instructions get 2-byte aligned. Patchable jals are remaining their 4-byte form, but now they might stay in a 2-byte alignment.
    An example:
0x0000003fe11b01fe:   jal	ra,0x0000003fe1126d80 (patchable)
0x0000003fe11b0202:   ...

Code is running at full speed on every hart. If this instruction is patched with unaligned access, the patching operation is not atomic anymore. In this respect, concurrency issues may occur, which are hard to address as pcs could fly to any place and the generated code seems to have no error.
We solve this issue by using ins_alignment(4) to force the patchable jals to stay in a 4-byte aligned address.

0x0000003fe11b0200:   jal	ra,0x0000003fe1126d80 (patchable)
0x0000003fe11b0204:   ...

Jtreg tests

com/sun/jdi/EnumTest.java
com/sun/jdi/RedefineCrossStart.java
java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java
java/util/stream/test/org/openjdk/tests/java/util/stream/mapMultiOpTest.java
java/util/ResourceBundle/Control/StressTest.java
java/nio/charset/coders/BashCache.java
java/nio/channels/AsynchronousSocketChannel/StressLoopback.java
java/net/HugeDataTransferTest.java
java/net/httpclient/LargeResponseTest.java

could reproduce this issue in small chances.

I have run these tests over nights to ensure the issue is solved. Also, other jtreg tests are passed.

Thanks,
Xiaolin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant