Galaxy s7 edge crash

[[Unknown]]

Interesting, it sounds like +/- 4096 (typical size of a page) and the 256 alignment (which seems large for a cache line) are working best. To confirm, with option 1 + 0xFF (which is the 4096 + 256 option), you haven't gotten any crashes?

Unfortunately, I don't feel 100% confident in this since the two components seemingly required don't seem related, and it doesn't totally make sense. I'm a little concerned that 256 is just leaving enough holes that it's significantly less likely to crash, but will eventually still crash. But, I'm not sure what else to try... Henrik?

Actually, I had one more idea. Instead of that one HINT part, what if you try:

Code:

for (int h = 0; h < 64; ++h) {
    HINT(HINT_NOP);
}

This will do a different thing than before. If this works also, it may mean that what we really need is space between blocks, not alignment. Since most blocks are pretty small, it might be that alignment was just giving us space.

If that does work, can you try 32 and 16 also, in place of 64? If it doesn't, there's no need to bother. If 64 doesn't work, those others are very unlikely to work.

The next thing is, what does it show under System Info? We might have to do this based on the "Name" under "CPU Information", I suppose.

I don't think it's interesting to try the other alignment values with block link off. If 0xFF works reliably and 0x3F doesn't, I don't expect that to be impacted by block linking.

---

To explain a bit about what's happening and what you're debugging -

Jit breaks the game's code into small pieces, called "basic blocks." These are typically short sections of MIPS code (that's the CPU the PSP has.) Then it translates that basic block into ARM64 code (which is what your phone's CPU uses.) Then the pieces of the program are stored in memory as jit blocks.

Normally, CPUs can count on program code not changing - sometimes they don't even look at the code, because they just want to go fast. They just run the program from "the instruction cache," which is like saying it knows the program by heart. When we change the code, we have to tell it - or it just won't know. This is what "invalidation" is.

Normally, after writing new code, we tell the operating system - I started writing new code HERE, and I finished with the new code HERE. So forget anything between those two places. The 4096 change makes us lie: we say we invalidated 1024 more bits of program code each direction than we really did.

Basic blocks are really small, but there's lots of them. 4096 bytes / 1024 instructions will probably cover many blocks. This will hurt performance (more or less depending on different CPUs), but usually only temporarily.

Block linking is a trick where we tie blocks together, directly. With block linking off, we run one block at a time. There's overhead while the jit reaches into its bag to pull out the next block. But sometimes, code goes in sequence - we can just send the CPU from one block directly to the next. To do this, after we've created both blocks, we go back and modify the first one to point directly to the second. This invalidates again (and with the changes, also invalidates +/- 1024 instructions.)

Lastly, the alignment makes it so every block starts at an "even" position. It's like if you started paragraphs on lined paper, only on every 5th line. If your first paragraph was 6 lines long, oh well, you'll just skip 4 lines to start the next one.

My big worry is that, aligning to 256 might mean that most blocks have a bunch of blank lines between them. This wastes the limited jit space some, but more importantly it could be it's only working when there's enough blank space between all blocks. Maybe the CPU really just wants two blank lines between each paragraph. Sometimes (it's not common), there will be larger blocks, and it could be these will still crash (i.e. when a boss uses an unusual and complicated move, or etc.)

-[Unknown]