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

Jitarm64: Implements spin-loop futex for JIT blocks #3356

Merged
merged 7 commits into from
Jan 23, 2024

Conversation

Sonicadvance1
Copy link
Member

@Sonicadvance1 Sonicadvance1 commented Dec 29, 2023

Needs #3339 merged first.

This will ensure that multiple concurrent SIGBUS handlers in the same
code block doesn't modify the same code.

@bylaws
Copy link
Collaborator

bylaws commented Dec 29, 2023

I feel like FutexSpinWait probably isn't the best name for this, I haven't see futex used to refer to anything but the Linux syscall, which this explicitly doesn't use

@Sonicadvance1
Copy link
Member Author

I feel like FutexSpinWait probably isn't the best name for this, I haven't see futex used to refer to anything but the Linux syscall, which this explicitly doesn't use

Renamed to SpinWaitLock

@alyssarosenzweig
Copy link
Collaborator

There's nothing appropriate in the stl? or provided by Linux? Why do we need to roll our own?

@Sonicadvance1
Copy link
Member Author

There's nothing appropriate in the stl? or provided by Linux? Why do we need to roll our own?

Nothing in the STL, libc, or Linux similar to a spin-loop.
Closest things end up being std::condition_variable or pthread_cond_t, or a kernel futex. All of these are too heavy for what is getting accomplished here, which is a spin-loop/spin-lock.

@Sonicadvance1 Sonicadvance1 force-pushed the modify_code_lock branch 2 times, most recently from 85b3dd2 to e75277b Compare January 13, 2024 03:14
This will only be used internally inside of FEXCore for efficient shared
codecach backpatch spin-loops.
This will ensure that multiple concurrent SIGBUS handlers in the same
code block doesn't modify the same code.
Need to have a source be +r so it doesn't get overwritten.
…d lock

We had a chance of doing an additional bogus wfe if the expected value
was hit in one iteration of a loop. Not the biggest problem on current
hardware where WFE only ever sleeps for 1-4 system cycles, but on future
hardware where WFE might actually sleep for longer then this could have
been an issue.
@lioncash lioncash merged commit 750b0b7 into FEX-Emu:main Jan 23, 2024
10 checks passed
@Sonicadvance1 Sonicadvance1 deleted the modify_code_lock branch January 23, 2024 18:47
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.

4 participants