Project

General

Profile

Actions

Emulator Issues #8738

closed

After loading multiple times savestates, Dolphin takes a huge part of memory

Added by Mafia1300 over 9 years ago. Updated almost 9 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Current
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

[READ THIS: https://forums.dolphin-emu.org/showthread.php?pid=276132 <<<
Your answers are there!]
[Leave the questions as they are and answer them in the next line]
[Remove lines written inside brackets [], but nothing else]

Game Name?
Any game

Game ID?
Any ID

What's the problem? Describe what went wrong in few words.
When I load like 50-60 times savestates, Dolphin starts to lag a lot, and takes a high memory (sometimes it can uses 2,5GB of memory)

What did you expect to happen instead?
Dolphin don't take a lot of memory

What steps will reproduce the problem?
[Don't assume we have ever played the game and know any level names. Be as
specific as possible.]
1.Launch a game
2.Load a lot of time savestates
3.See

Dolphin 3.5 and 3.5-367 are old versions of Dolphin that have
known issues and bugs, so don't report issues about them and test the
latest Dolphin version first.
Which versions of Dolphin did you test on?
I tested this on last Dolphin version

Does using an older version of Dolphin solve your issue? If yes, which
versions of Dolphin used to work?
I tested also on 3.0-1749, and it didn't made this.

What are your PC specifications? (including, but not limited to: Operating
System, CPU and GPU)
Windows 8/8.1
i7-3770 3.4GHz
GT 620
ASUS PC.

Is there any other relevant information? (e.g. logs, screenshots,
configuration files)
[Upload big files to a hosting service and post links here!]
Nothing, I'm gonna test Dolphin versions to see at around which versions it does this :p
Thanks for taking your time to fix glitches :)

[Do not attach files to this issue. Upload them to another site and
link here. Use imgur.com for images and pastie.org for logs. Monitor the
email address that was used to create this issue.]

Actions #1

Updated by Mafia1300 over 9 years ago

Forgot to add, you can load the same savestate and you don't have to do anything inbetween. :P

Actions #2

Updated by marwinmisselhorn over 9 years ago

Same for me. After like 100 times my entire RAM is basically taken by Dolphin lol

Actions #3

Updated by Mafia1300 over 9 years ago

Yep, that's really like YOLO problem, I'm pretty sure it's gonna get fixed soon :D

Actions #4

Updated by Anonymous over 9 years ago

The size of a save-state can vary by game. Brawl's save-states are typically around 65MB in size, whereas Worms 3D's are only around 9MB.

Actions #5

Updated by Mafia1300 over 9 years ago

65MB O_o, the memory stacks up so fast then :/
I really hope this glitch can be fixed :D
Thanks

Actions #6

Updated by hk.konpie over 9 years ago

I seem EmuCodeBlock protect member is one of the main causes. Those unordered_map is not clear.

Actions #7

Updated by Mafia1300 over 9 years ago

Ah, cool you found one of the causes, that'll help a lot!

Actions #8

Updated by Fog over 9 years ago

can confirm that this is a valid issue, not sure if it's release blocking as it has been around since 3.5 at least

Actions #9

Updated by hk.konpie over 9 years ago

I analyze a bit those unordered_map, it's result have 2 problem.

  1. When load state, not consider these.(this issue, one of the causes)
    Most games are around several MB.
    (specification implement jit? a tacit understanding since several years?)
  2. Regardless load state, it enlarged steadily by specific game.
    for exmaple, The Last Story(SLSJ01).
    (Last Story start, leave anything without play it. And disconnect wiimote guidance. Monitoring dolphin process memory.)
    Sorry my bad English.
Actions #10

Updated by Mafia1300 over 9 years ago

By the way, it seems to happens on Linux too. didn't tested on a mac

Actions #11

Updated by JMC4789 over 9 years ago

  • Status changed from New to Accepted
  • Milestone set to Current
Actions #12

Updated by moncef.mechri over 9 years ago

I'm looking into this issue.

Actions #13

Updated by moncef.mechri over 9 years ago

I cannot reproduce this issue on Archlinux x86_64.

I made saves of Smash Bros Brawl using the Fn keys and tried to load them many times while monitoring the memory usage in htop. The loading works fine but I don't see any change in memory consumption.

And I did try both a Debug build and a Release build

Actions #14

Updated by Fog over 9 years ago

seems like to be a Windows exclusive issue(?)

Actions #15

Updated by JosJuice about 9 years ago

The memory usage increases when loading a savestate and then letting Dolphin run for a second or so. It doesn't happen when loading savestates when Dolphin is paused. This fits with what hk.konpie found - the JIT is only adding entries to the unordered_maps when it's running.

Actions #16

Updated by hk.konpie about 9 years ago

In my #7 comment

  1. Regardless load state, it enlarged steadily by specific game.
    for exmaple, The Last Story(SLSJ01).

Have no relationship to this issue8738.
This was due to another.
(The cause was dcbi instruction in LCDisable. LCDisable is executed every 1fps, maybe. As a result, exception handler(JIT_PPC_00000xxx) is generated repeat every 1fps. This seem bug to me. Another for example, Tower of Pandora(SX3J01), ONEPIECE UC EP1(ROUJAF)&EP2(RIUJAF).)

Actions #17

Updated by JosJuice almost 9 years ago

HdkR looked into this today and reproduced it on Ubuntu. Some of the conclusions:

(15:27:18) HdkR: I'm also 100% sure that it isn't an issue with our block cache
(15:33:47) Fog_TAS: hmm
(15:33:52) Fog_TAS: where does that leave us?
(15:35:48) HdkR: Iunno
(15:36:07) HdkR: Figure out what is leaking the memory instead of blaming the block cache?
(15:37:18) Fog_TAS: I'm guessing the unordered_map was the block cache
(15:37:20) Fog_TAS: ?
(15:37:24) JosJuice: Should be somewhere in the JIT code at least, since there were reports that it doesn't happen with interpreter
(15:38:00) HdkR: JosJuice: Or that they didn't wait long enough between state loads to see it
(15:38:05) JosJuice: Also possible
(15:38:27) JosJuice: Yeah, now that I think about it, that doesn't sound unlikely at all
(15:38:38) HdkR: If it is something on the GPU then I wouldn't be surprised

It also seemed like the memory usage was increasing faster when EFB to RAM was used. Please correct me if I missed something important.

Actions #18

Updated by hk.konpie almost 9 years ago

These unordered_maps should originally clear it after ClearCodeSpace().
sample patch (but very old): http://pastebin.com/qJXU5KBP
Sorry my bad english from japan.

Actions #19

Updated by Fog almost 9 years ago

hk.konpie wrote:

These unordered_maps should originally clear it after ClearCodeSpace().
sample patch (but very old): http://pastebin.com/qJXU5KBP
Sorry my bad english from japan.

English is fine, no need to worry.

Anyways, I've tested the patch and it mitigates the expanding RAM usage (clears it once it reaches a certain point) but doesn't solve why it's actually growing. However, it's better than nothing.

Actions #20

Updated by hk.konpie almost 9 years ago

but doesn't solve why it's actually growing.

Do you try insert JitInterface::ClearCache() in State.cpp?
if (loadedSuccessfully)
{
JitInterface::ClearCache();

Actions #21

Updated by Fog almost 9 years ago

hk.konpie wrote:

but doesn't solve why it's actually growing.

Do you try insert JitInterface::ClearCache() in State.cpp?
if (loadedSuccessfully)
{
JitInterface::ClearCache();

I actually cleared the cache within JitInterface instead, just put my pull request up here: https://github.com/dolphin-emu/dolphin/pull/3535

Actions #22

Updated by JMC4789 almost 9 years ago

  • Status changed from Accepted to Fix pending

Fixed in PR 3535

Actions #23

Updated by JMC4789 almost 9 years ago

  • Status changed from Fix pending to Fixed

Fixed by 4.0-8735

Actions

Also available in: Atom PDF