On Fri, Nov 15, 2024 at 5:38 AM 'Ronald Fenner' via v8-dev < [email protected]> 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 [email protected] > 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 < >> [email protected]> 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 >>> [email protected] >>> 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 [email protected]. >>> 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 >> >> [email protected] >> >> 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 > [email protected] > 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 [email protected]. > 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 [email protected] 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAH3p7oN_mURgxiy9i_j9%2BMaWRfMiFG4Q0nipe54E7Drs6hfaSg%40mail.gmail.com.
