I played around with some of my ideas and ended tracking the order they get created in a vector and then when the App is disposed of it iterates over the vector in reverse this solved the issue I was running into.
For some reason even though the creator immediately called Enter on the isolate and I called Exit after it's created I later ran into an error still when trying to reenter the isolate and destroying the creator. Also I'm not trying to take a snapshot in a controlled manor so the app itself would know when it's doing a snapshot and the users would be able to run code designed to be snapshot vs just running stuff as a normal run of it. On Tuesday, November 26, 2024 at 4:06:31 PM UTC+8 jgr...@chromium.org wrote: > On Fri, Nov 15, 2024 at 5:38 AM 'Ronald Fenner' via v8-dev < > v8-...@googlegroups.com> wrote: > >> After digging through my code and looking at the comments for the >> creation of the SnapshotCreator i see it explicitly enter the isolate >> however it does not look like it exits until destroye. Thus my creating >> multiple snapshot creators ahead of time is where the issue arises due to >> the stack of entered isolates and why destroying them in the reverse order >> of snapshotting works doesn't hit the error. >> >> This brings up some questions I think you may have hinted at. >> >> My assumptions where isolates were entirely isolated and thus >> snapshotting should only affect that isolate itself thus my pairing and >> isolate and creator when i know the runtime is created for snapshotting, >> however it seems snapshotting may also affecte some shared data structures >> thus when snapshotting you can only do one per process run. >> > > Hi Ronald, please excuse the late reply. > > When the gn arg `v8_enable_extensible_ro_snapshot` is set, snapshotting > can modify RO space which is shared between isolates. Otherwise, its > effects should be limited to the snapshotted isolate. > > Again, snapshotting 1) mutates the isolate and 2) doesn't support > arbitrary heap states. > > >> >> Could i take multiple snapshots but i would need to >> create->snapshot->destroy the creator before I snapshot another. >> >> What is the reasoning behind having the creator explicitly entering the >> runtime rather than allowing for the embedder of telling it when to enter >> it >> >> Can I fix the issue with something as simple as calling Exit on the >> isolate after creation and resolve the issue or does it need to remain >> entered. >> > > I don't think there's a reason besides SnapshotCreator being written with > our main use cases in mind. Would it work for you to snapshot your isolates > one after another, only having one SnapshotCreator active at a time? > > >> >> >> On Thursday, November 14, 2024 at 6:30:32 PM UTC+8 jgr...@chromium.org >> wrote: >> >>> The SnapshotCreator is unfortunately not as flexible as you describe. >>> Specifically: >>> >>> 1. taking a snapshot also mutates the snapshotted Isolate, and >>> 2. snapshotting doesn't fully support arbitrary heap states. See here >>> <https://source.chromium.org/chromium/chromium/src/+/main:v8/test/mjsunit/mjsunit.status;l=1906;drc=981ce1e8f82050b33153a9c4652f2ad1cefabff1> >>> for >>> a list of known test failures in our test variant that attempts to do just >>> that. >>> >>> The only workflow that is extensively tested on our side is essentially >>> what mksnapshot does, i.e.: we take a single snapshot of a well-known, >>> simple heap state and afterwards throw away the Isolate. You can always >>> attempt more advanced scenarios, but I wouldn't be surprised if you soon >>> run into trouble when snapshotting arbitrary heap states / continuing to >>> use the Isolate after. >>> >>> On Wed, Nov 13, 2024 at 7:18 AM 'Ronald Fenner' via v8-dev < >>> v8-...@googlegroups.com> wrote: >>> >>>> I'm testing my sanpshotting process and I create multiple snapshots at >>>> one time. since the main app can have multiple runtimes that it could >>>> snapshot. >>>> >>>> When i go to tear down the Isolates and creators i get this error >>>> # Debug check failed: CurrentPerIsolateThreadData()->isolate_ == this. >>>> >>>> I found after doing some testing that if i teardown the creators and >>>> isolates in the reverse order they were snapshotted in then there is no >>>> error. >>>> >>>> It seems like the snapshoot process isn't fully restoring something and >>>> thus the error occurs. >>>> >>>> I know I can code around it my destorying the isolate and creator as >>>> soon as i take the snapshot however this seems like a bug and I was >>>> planning on be able to have a app that can create snapshots while also >>>> having it's own runtime it's running and not sure if it would cause it >>>> problems. >>>> >>>> The basics of the flow is a runtime class is created which if the >>>> runtime is going to be snapshoted the runtime and created are paired and >>>> stored within the class. >>>> When the snapshot process is called the runtimes are looped over and a >>>> snapshot is created of each. When the runtime is torn down the isolate and >>>> creator are then destroyed. >>>> Note i'm storing the runtimes in a std::map so their order of iteration >>>> apparently can change so this creates the issue. >>>> >>>> I was able to test the order since the app class has it's main runtime >>>> and then the additional and by changing the order in which the main and >>>> hte >>>> additional runtime were torn down it worked, however adding a third the >>>> problem reoccured most likely due a possibly different order of iteration >>>> on the map. >>>> >>>> I looked for a way to try and pop the isolate or something and even >>>> tried entering and exiting but that didn't help. >>>> >>>> -- >>>> -- >>>> v8-dev mailing list >>>> v8-...@googlegroups.com >>>> http://groups.google.com/group/v8-dev >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "v8-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to v8-dev+un...@googlegroups.com. >>>> To view this discussion visit >>>> https://groups.google.com/d/msgid/v8-dev/5d6392f5-a26a-41a9-8d77-974032d0e69an%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/v8-dev/5d6392f5-a26a-41a9-8d77-974032d0e69an%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> Jakob Gruber >>> >>> Software Engineer >>> >>> jgr...@google.com >>> >>> Google Germany GmbH >>> >>> Erika-Mann-Straße 33 >>> >>> 80636 München >>> >>> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >>> >>> Registergericht und -nummer: Hamburg, HRB 86891 >>> >>> Sitz der Gesellschaft: Hamburg >>> >>> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten >>> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, >>> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, >>> dass die E-Mail an die falsche Person gesendet wurde. >>> >>> >>> This e-mail is confidential. If you received this communication by >>> mistake, please don't forward it to anyone else, please erase all copies >>> and attachments, and please let me know that it has gone to the wrong >>> person. >>> >> -- >> -- >> v8-dev mailing list >> v8-...@googlegroups.com >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to v8-dev+un...@googlegroups.com. >> > To view this discussion visit >> https://groups.google.com/d/msgid/v8-dev/80b2bb0a-3f3f-4862-b891-f7f04ee21c56n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/v8-dev/80b2bb0a-3f3f-4862-b891-f7f04ee21c56n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/a98cbc3f-eef7-4fc9-96f2-044c44da7774n%40googlegroups.com.
