| | <<<Back 1 day (to 2018/03/26) | 20180327 |
| fredross-perry | Here is what I did to your scavenging commit: http://git.ghostscript.com/?p=user/fred/mupdf.git;a=commit;h=be0c760b140f44035ce110a18aa05291f6933968 | 00:02.41 |
| | well, the one before that. | 00:03.11 |
| | note: fixed a few issue not related to scavenging. | 00:03.50 |
| moolc | tor8: https://youtu.be/LhMRAjX95k0 | 13:37.09 |
| fredross-perry | robin, sebras. possible false start with Silver's latest build. I grabbed everything from Robin's branch to get his scavenging commit, then hacked it up. Silver then says he worked for hours without a crash. What's on that branch? And, I used the system command 'free' to display memory info, which was missing on his device. He had one crash, and the log indicates that scavengin was attempted twice before giving | 14:43.21 |
| | up. | 14:43.21 |
| Robin_Watts | fredross-perry: Random stuff on that branch, probably not too much to upset stuff. | 14:45.13 |
| fredross-perry | But nothing that would cause it to work successfully for much longer? | 14:45.47 |
| Robin_Watts | fredross-perry: Only the attempting to scavenge stuff. | 14:46.27 |
| fredross-perry | From the one log he attached, it only happened once, and resulted in a crash anyway. What that build does not do, of course, is to go ahead and throw the exception and see if the issue persists. | 14:47.40 |
| sebras | ok, so the first attempt to scavenge memory freed everything possible but that was not enough to make the call to AndroidBitmap_lockPixels() succeed. | 15:00.55 |
| | and at the next attempt to scavenge memory, nothing could be scavenged, so we failed and called abort(). | 15:01.25 |
| fredross-perry | yes, understood. | 15:02.09 |
| | robin - look at my commit (a revised version of yours) and see if I F'ed something up, thanks. | 15:03.15 |
| | it's in the log from yesterday | 15:03.26 |
| Robin_Watts | fredross-perry: Well, the last hunk shouldn't be there, but that's unlikely to make a difference. | 15:07.29 |
| fredross-perry | last hunk? | 15:07.48 |
| sebras | Robin_Watts: is it noteworthy that the file that files for the reporter is the same one that frequently used to cause " | 15:08.22 |
| | app is not responsive" warnings. | 15:08.30 |
| Robin_Watts | fredross-perry: http://git.ghostscript.com/?p=user/fred/mupdf.git;a=commitdiff;h=be0c760b140f44035ce110a18aa05291f6933968 | 15:08.48 |
| sebras | does that mean that he used to kill the app at that time? | 15:08.51 |
| Robin_Watts | That's what we're talking about, right? | 15:08.57 |
| sebras | Robin_Watts: the log appears to match that commit. | 15:09.31 |
| | Robin_Watts: and it is the same commit that fred linked to yesterday night. | 15:10.03 |
| fredross-perry | including the word 'scavening' - I invented it. | 15:10.27 |
| | The 'not responsive' does not surprise me, he'z zoomed out to show 6 pages at once and scaling, so lots of rendering. | 15:11.41 |
| sebras | there is an interesting line in the log: lowmemorykiller attempted to write the oom_score_adj but failed to do so and got EINVAL. | 15:13.09 |
| | and the PID matches that of muso. | 15:13.32 |
| | so that tells us that some service thinks we are eating too much memory. | 15:13.45 |
| | fredross-perry: ok, however the 'not responsive' warning still indicates that we haven't got the threading right. even if the rendering takes tile we shouldn't be blocking the UI. | 15:16.51 |
| fredross-perry | Right. But I am pretty sure the rendering is happening in the background. | 15:18.08 |
| sebras | fredross-perry: I'm not sure it is related but you have seen the NullPointerException mentioned in the log..? | 15:26.49 |
| fredross-perry | missed that one. Odd. | 15:29.12 |
| sebras | fredross-perry: also the Choreographer service complains that the app is doing too much work on its main thread. | 15:29.43 |
| | I guess that leaves us with the option of implementing an allocator which has an upper limit of how much it may allocate. | 15:43.47 |
| fredross-perry | one of the test files from Silver has six pages, and on my Pixel C, when fully zoomed-out, each page takes about 2 secs to render. This takes place off the main thread, but I don't know what the thread scheduling algorithm is like. | 16:05.32 |
| | sebras, tor8 - I'm not sure the java Cookie interface is correctly aborting. This may have something to do with onethread wanting to set cookie->abort, but the rendering is happening in a different thread. | 16:50.00 |
| Robin_Watts | fredross-perry: (For the logs) The point of the cookie is that it works across threads. | 16:53.13 |
| sebras | fredross-perry: what makes you think it does not work correctly. | 16:54.10 |
| | ? | 16:54.12 |
| Robin_Watts | fredross-perry: The point of the cookie is that it works across threads. | 17:07.22 |
| | There is no locking involved. | 17:07.28 |
| fredross-perry | Hmm. | 17:07.32 |
| Robin_Watts | BUT... we had a report recently that the cookie was taking a long time to take effect. | 17:08.00 |
| | So, at the staff meeting I scribbled a proposal to fix that. | 17:08.21 |
| fredross-perry | So I edited list-device.c and looked for any change in the cookie during fz_run_display_list, and saw none. | 17:08.24 |
| | ... and I know I am setting it. I think. | 17:08.46 |
| HenryStiles | just wanted to keep up we have dismissed cmake and are now looking at premake? Or is cmake still possible? | 17:09.00 |
| Robin_Watts | fredross-perry: You looked for cookie.abort beingset ? | 17:09.06 |
| | HenryStiles: premake is looking preferable at this stag. | 17:09.15 |
| | +e | 17:09.18 |
| | The makefiles output by cmake are machine specific. | 17:09.31 |
| | so we can't check those in to git, and include them in releases. | 17:09.54 |
| fredross-perry | well,... | 17:09.55 |
| | if (cookie->abort) | 17:09.56 |
| | { | 17:09.57 |
| | LOGI("list-device breaking"); | 17:09.58 |
| | break; | 17:09.59 |
| | } | 17:10.00 |
| HenryStiles | Robin_Watts: oh I didn't know that | 17:10.00 |
| Robin_Watts | HenryStiles: Nor did I until tor8 tried yesterday :) | 17:10.14 |
| | Supposedly the output from premake looks much saner. | 17:10.34 |
| | I need to check the VS output at some point. | 17:10.42 |
| | fredross-perry: OK, so if you're not seeing that set, and you believe you're setting it, that's a problem. | 17:11.14 |
| jogux | HenryStiles: I didn't know it either. TBH cmake explicitly say "These are generated files, don't check them in". | 17:11.20 |
| fredross-perry | robin - that's my belief. | 17:11.40 |
| sebras | fredross-perry: how do you know that the abort flag is set? | 17:12.27 |
| Robin_Watts | fredross-perry: The other possibility is that there is just 1 entry in the display list, and that entry is taking ages to render, and hence the abort flag isn't being checked cos we check before each item. | 17:12.28 |
| | That might be the case on files which have just 1 large image per page. | 17:12.47 |
| fredross-perry | right. But I am also testing it on some files that are not image-heavy. | 17:13.25 |
| | Anyway, could there be some sync issue between threads? | 17:13.50 |
| Robin_Watts | fredross-perry: There could. | 17:16.10 |
| | The cookie is just an area of memory. | 17:16.42 |
| | If each thread had its own cache, then writing it in one thread might not update the copy in another threads cache. | 17:17.36 |
| | (I mean core on which the thread is running, IYSWIM). | 17:17.53 |
| | I'd be tempted to add logging that printed the address of cookie->abort when it's checked, and when it's written. | 17:18.54 |
| | That way we can at least be sure that we are looking at the same thing on both sides! | 17:19.16 |
| fredross-perry | i'll do that. | 17:21.32 |
| | Aha! I was creating a new cookie each time using 'final', and getting a different address each time. If I make the cookie at the object level, it stays in one place and works now. | 17:40.04 |
| Robin_Watts | fredross-perry: You want a unique cookie per render. | 17:57.51 |
| | How this works in java has fallen out of cache. | 17:58.08 |
| fredross-perry | hmm. | 17:58.16 |
| Robin_Watts | but as long as you're happy that you get a unique cookie per render, we should be fine. | 17:58.27 |
| fredross-perry | I have a unique cookie per page, and (presumably) one render par page at a time. | 17:58.38 |
| Robin_Watts | fredross-perry: One render per page seems reasonable, yes. | 17:58.55 |
| | actually.... | 17:59.23 |
| | you allocate Bitmaps the size of the android screen right? | 17:59.33 |
| | And then draw different pages into subareas of those bitmaps? | 17:59.44 |
| fredross-perry | Yes. | 17:59.59 |
| Robin_Watts | given each render will attempt to lock the while bitmap, I'd hope that you've only got one render per BITMAP, not one render per page. | 18:00.25 |
| | s/while/whole/ | 18:00.33 |
| fredross-perry | Sorry, yes. It is one render operation at a time. Each page has it's own render -object- for tracking things. Sorry for confusion. | 18:02.35 |
| Robin_Watts | no worries. | 18:16.36 |
| | Forward 1 day (to 2018/03/28)>>> | |
Log of #mupdf at irc.freenode.net.