| | <<<Back 1 day (to 2018/05/07) | 20180508 |
| kens | pda1224a (for the logs) we would need to see the file (to find out where the space is used) and know what you have already tried before being able to make any suggestions. | 07:02.04 |
| Robin_Watts | kens, chrisl: So I have some gc issues with my pixel_patch stuff. | 13:19.48 |
| | I guess that's not surprising. | 13:19.54 |
| kens | Oh :-( | 13:19.55 |
| | I'd have thought it was surprising | 13:20.06 |
| | I wouldn't have thought you were using GC memory.... | 13:20.14 |
| Robin_Watts | When you call pixel_patch with pixel_patch_begin, it allocates state. | 13:20.17 |
| kens | Why do you allocate it in GC memory though ? | 13:20.28 |
| Robin_Watts | and one of the things in that state is a gx_device *. | 13:20.29 |
| | kens: I probably shouldn't, and that's easy to solve. | 13:20.41 |
| kens | Unless you need to pass it ot the PS interpreter, I wouldn't be using GC memory | 13:20.58 |
| Robin_Watts | BUT... a gx_device * is garbage collected, right? | 13:20.59 |
| kens | Yes, btu that doesn't mean anythign which stores it has to be | 13:21.09 |
| Robin_Watts | Ah. | 13:21.17 |
| kens | Its also only GC'ed on the PS itnerpreter | 13:21.21 |
| | It won't be in a PCL interpreter for example | 13:21.32 |
| Robin_Watts | I was thinking that I would have to enumerate it on a gc, otherwise it might get moved without me knowing ? | 13:21.46 |
| kens | You probably want Chris to weight in htere though | 13:21.54 |
| | It could potentially be relocated yes | 13:22.20 |
| | That's a good point | 13:22.24 |
| Robin_Watts | So I fear I need to put this stuff in gc memory, and have an enumerator etc. | 13:22.47 |
| kens | It sort of sounds like it | 13:23.01 |
| | I'm uncertain about devices though I admit | 13:23.10 |
| | I guess on non-GC interpreters the device won't relocate, so we don't care. | 13:24.14 |
| Robin_Watts | I am 99% sure I need to enumerate it. | 13:26.34 |
| HenryStiles | kens, Robin_Watts : I don't see how language switching would work at all if devices can be relocated, I don't recall that coming up in the LS system, there were other problems. | 13:26.46 |
| kens | was sort of hoping Chris would pop up but I guess he's AFK | 13:26.57 |
| Robin_Watts | He'll be back soon I'm sure. | 13:27.13 |
| | Devices look to always be allocated sing gs_alloc_struct_immovable. | 13:30.52 |
| | So I might be saved by that. | 13:31.13 |
| chrisl | Robin_Watts: We can talk after the meeting about devices etc | 14:35.13 |
| Robin_Watts | chrisl: Ta. | 14:35.22 |
| chrisl | Robin_Watts: So, as you noted, devices should *always* be allocated in immovable memory, so the device cannot move, but it can be garbage collected | 15:03.45 |
| Robin_Watts | chrisl: So if I have a pointer to a device in a structure, it could theoretically be whipped away from under me. | 15:04.18 |
| chrisl | Robin_Watts: That rather depends.... if it's the device in the graphics state, then no | 15:05.12 |
| Robin_Watts | This structure only lives for the life of the image enumerator though, so I suspect it should be fine, as penum->dev should hold it. | 15:05.25 |
| chrisl | Yes, that will ensure it endures | 15:05.55 |
| Robin_Watts | (or penum->rop_dev or penum->clip_dev - horrible. Shame on whoever came up with that) | 15:06.04 |
| | chrisl: Thanks. | 15:06.51 |
| chrisl | Well, that's just a hack, frankly | 15:06.52 |
| Robin_Watts | The SEGVs have gone. | 15:07.01 |
| | Now to fix the diffs... | 15:07.07 |
| chrisl | Since both the clip device and the rop device act as forwarding devices, sane use of reference counting should obviate the need for individual pointers to each, but.... ho-hum | 15:08.03 |
| | Robin_Watts: just before you disappear into tracking down diffs, can you take a quick look at: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=f302fbc59b974a167a7a0023ac6f9e89ed27d243 | 15:09.18 |
| kens | Hmm is that the root cause of the memory problem you were looking at ? | 15:10.52 |
| chrisl | Yes | 15:11.09 |
| kens | Ah! | 15:11.16 |
| chrisl | So, I was sort of right :-) | 15:11.39 |
| kens | It makes the problem a little less horrifying :-) | 15:11.55 |
| chrisl | I still wonder how it's not come up before | 15:12.17 |
| kens | It does seem surprising, yes | 15:12.36 |
| | Will be nice to have it fixed | 15:12.47 |
| Robin_Watts | chrisl: I know nothing about c_alone. | 15:17.04 |
| | which is presumably why I screwed that up. | 15:17.10 |
| chrisl | Is that yours? I thought that had been there for ever | 15:17.29 |
| Robin_Watts | oh, I assumed it was something I broken in the clump change. | 15:17.47 |
| | the splay trees stuff, but I guess not. | 15:18.00 |
| chrisl | No, just that you were that last person to do significant poking in that file..... | 15:18.07 |
| Robin_Watts | I bow to your greater knowledge here. It looks plausible to me | 15:18.13 |
| chrisl | Anyway, I'll take that as a positive review, and push the commit :-) | 15:19.53 |
| Robin_Watts | you should. | 15:20.26 |
| | Forward 1 day (to 2018/05/09)>>> | |
Log of #ghostscript at irc.freenode.net.