01:23:27  * plutoniixjoined
01:38:07  <devsnek>does anyone know how a v8 eternal that has been set could be empty
01:42:33  * Guest26011quit (Quit: Lost terminal)
01:45:33  <devsnek>caitp: do you know anything about eternal handles?
01:46:49  <caitp>could be that you're setting it during snapshot creation and the eternal handle set from the snapshot isn't being deserialized?
01:46:56  <devsnek>i'm not doing any snapshots
01:47:03  <caitp>then, no idea
01:47:18  <devsnek>i set it and then after that every call to IsEmpty is true
01:47:31  <caitp>immediately after it?
01:47:33  <devsnek>as soon as the scope i set it in closes
01:47:38  <devsnek>i think*
01:47:44  <devsnek>its hard to like actually test that
01:48:24  <devsnek>but if i do like `eternal.Set(...); eternal.IsEmpty()` its false
01:48:42  <devsnek>then like a tick later i go to grab the function i stored in it
01:48:44  <devsnek>and the eternal is empty
01:48:46  <caitp>can you point to this code on your github?
01:48:55  <devsnek>sure
01:49:11  <devsnek>https://github.com/devsnek/ivan/blob/master/src/ivan_util.cc#L72
01:49:14  <devsnek>also another interesting thing
01:49:17  <devsnek>i have two eternals
01:49:20  <devsnek>one of them works fine
01:49:36  <devsnek>i call the eternal here https://github.com/devsnek/ivan/blob/master/src/ivan.h#L125
01:49:56  <devsnek>https://www.irccloud.com/pastebin/xNjDr0dr/
01:50:09  <devsnek>test/a.js is in the repo but it isn't that important
01:52:36  <caitp>is it always the same isolate?
01:52:43  <devsnek>yea i only have one isolate
01:53:15  <devsnek>i haven't graduated to working on multithreading yet :p
01:55:53  <caitp>what about the js calling your C++ functions
01:55:58  <devsnek>wdym
01:56:07  <caitp>a.js
01:56:14  <devsnek>a.js doesn't call those
01:56:18  <devsnek>they're both called in lib/ivan.js
01:56:37  <caitp>I'd still like to see the test itself, but I'll take a look at ivan.js
01:56:47  <devsnek>https://github.com/devsnek/ivan/blob/master/test/a.js
01:56:51  <devsnek>its not much of a test
01:57:42  <devsnek>i just pulled the latest lkgr and i'm building it now... maybe there was just some bug
01:57:48  <devsnek>fingers crossed
01:57:53  <devsnek>or maybe you'll spot some dumb mistake i made
01:58:36  <caitp>i've been busy with webkit lately so I'm not sure about any recent fixes to that in v8
02:02:20  <devsnek>i'm still hopeful i've just got some stupid mistake somewhere 😢
02:06:58  <caitp>it might be good to add a string to the printf in InternalCallbackScope to see where each one is happening from --- I only see 2 uses of it on github, and I'm guessing it's not the one in ivan_plaform.cc, bbut not 100% sure
02:07:25  <caitp>still, hard to say what it is... need to inspect what is happening with Eternalandles
02:08:09  * s1341_joined
02:08:40  * littledan_joined
02:08:53  * Garbee_joined
02:09:00  * devsnek_joined
02:12:50  * s1341quit (Ping timeout: 256 seconds)
02:12:50  * Garbeequit (Ping timeout: 256 seconds)
02:12:50  * devsnekquit (Ping timeout: 256 seconds)
02:12:51  * littledanquit (Ping timeout: 256 seconds)
02:12:53  * s1341_changed nick to s1341
02:12:53  * Garbee_changed nick to Garbee
02:12:53  * littledan_changed nick to littledan
02:12:57  * devsnek_changed nick to devsnek
02:14:38  <caitp>I don't fully understand how EternalHandles works, since it looks like it doesn't prevent new space objects from being promoted, unless that's being prevented somewhere else? seems like that would make Eternal useless for not pretenured objects
02:15:03  <caitp>you could try forcing it to be pretenured and see if that fixes it, I guess
02:15:03  <devsnek>i dunno what any of that means
02:15:13  <devsnek>;-;
02:16:01  <devsnek>caitp: is there some code i need to add in or some way i need to call this then?
02:16:23  <caitp>I'm not sure the API gives you a direct way to allocate an object pretenure
02:16:26  <caitp>but uh
02:16:28  <caitp>let me see
02:16:36  <devsnek>internal::FunctionLiteral::pretenure
02:16:39  <devsnek>is the only thing
02:16:52  * Pablo[m]quit (Ping timeout: 245 seconds)
02:16:53  <devsnek>i'm still not sure what pretenuring is
02:20:09  <caitp>it's a generational GC, so new objects are usually put in "new space" and promoted to old space if they live long enough --- so they can move --- objects in old space can also move by compaction, etc
02:20:32  <caitp>so because of that, it's unclear how we could expect `val_` pointer to keep being valid, unless it was updated bby EternalHandles --- but I don't see how that's happening
02:20:39  <caitp>the v8 codebase is kind of a pain to read
02:20:45  <devsnek>so this could be some v8 bug
02:20:51  <caitp>well, I'm not sure
02:20:56  <devsnek>cuz all that should be transparent to v8 public api right
02:21:04  * plutoniixquit (Quit: Leaving)
02:21:10  <caitp>I'm definitely not the heap expert :( it's cool stuff but I don't really have the expertise in that area
02:24:20  <devsnek>and i have even less hehe
02:24:43  <devsnek>do persistents handle the heap movement?
02:29:33  <caitp>I think the difference between eternal and persistent is that Persistent objects aren't heap roots, so they can be collected? but otherwise, it's really, really hard to tell what is going on in the heap
02:30:44  <caitp>you might want to try using an older version of v8 just to see if a bug was introduced at some point
02:30:46  <devsnek>persistent is also empty
02:31:14  <devsnek>i suppose i can try checking out like 6.7
02:34:09  <caitp>what about dynamic linking
02:34:31  <caitp>are you doing any of that in this thing? is it possible that you ave more than one copy of the persistent in different object files or libraries?
02:35:23  <devsnek>i compile some static libraries
02:35:26  <devsnek>v8_monolithic target
02:35:37  <devsnek>and i actually just rebuilt it
02:37:31  <caitp>I dunno, but it's late, I have to go
02:37:45  <caitp>good luck, you might want to try posting on v8-users aobut it
02:38:12  <devsnek>thanks
03:18:11  * plutoniixjoined
03:23:18  * plutoniixquit (Quit: Leaving)
05:53:32  * chrisdickinsonquit (Ping timeout: 256 seconds)
05:53:53  * chrisdickinsonjoined
06:32:23  * plutoniixjoined
08:49:39  * Pablo[m]joined
09:39:21  * Pablo[m]quit (Ping timeout: 240 seconds)
10:19:51  * Pablo[m]joined
10:25:09  * mylesborinsquit (Quit: farewell for now)
10:25:39  * mylesborinsjoined
11:00:09  * AtumTjoined
11:50:45  * plutoniixquit (Remote host closed the connection)
13:09:44  <trungl-bot`>Tree closed by buildbot@chromium.org: closed (https://ci.chromium.org/buildbot/client.v8.ports/V8%20Mips%20-%20builder/16733 from f5d308510aaaa52893ca8c1ec271ad88b6c8cc8a)
13:11:45  <trungl-bot`>Tree closed by jgruber@chromium.org: closed (jgruber fixing https://ci.chromium.org/buildbot/client.v8.ports/V8%20Mips%20-%20builder/16733 from f5d308510aaaa52893ca8c1ec271ad88b6c8cc8a)
13:16:48  <trungl-bot`>Tree opened by jgruber@chromium.org: open
13:42:59  <trungl-bot`>Tree closed by buildbot@chromium.org: closed (https://ci.chromium.org/buildbot/client.v8/V8%20Linux64%20-%20custom%20snapshot%20-%20debug/21175 from 9b2bb40448a9a00d2946b021bd5af09ee5b9f066)
13:43:59  <trungl-bot`>Tree opened by jgruber@chromium.org: open
15:03:48  * dobsonquit (Quit: Leaving)
15:07:24  * dobsonjoined
16:51:45  * RT|Chatzillaquit (Read error: Connection reset by peer)
17:26:11  * seventhjoined
17:58:35  * Wes-joined
18:57:26  <trungl-bot`>Tree closed by buildbot@chromium.org: closed (https://ci.chromium.org/buildbot/client.v8.ports/V8%20Arm/6945 from b66226828fdc3b2c02a02b5a2a9e64ea0c92432e)
19:28:34  * seventhquit (Remote host closed the connection)
22:34:55  * RT|Chatzillajoined
23:20:13  * AtumTquit (Remote host closed the connection)