[v8-users] Problem linking when implementing V8InspectorClient
We have code that implements v8_inspector::V8InspectorClient and when we upgraded to V8 13.1.36 (thought he problem looks like it's there up to 13.1.99) we get the following when we try to link: ld64.lld: error: undefined symbol: typeinfo for v8_inspector::V8InspectorClient >>> referenced by /Users/imagine/src/inspector.cc >>> out/arm64.mac.release/obj/inspector.o:(symbol typeinfo for imagine::InspectorClient+0x10) >>> did you mean: vtable for v8_inspector::V8InspectorClient >>> defined in: v8/out/arm64.mac.release/obj/libv8_monolith.a(v8-inspector-impl.o) clang++: error: linker command failed with exit code 1 (use -v to see invocation) This seems to be because the following newish virtual functions in the base class have no default implementation: virtual void consoleTime(v8::Isolate* isolate, v8::Local label); virtual void consoleTimeEnd(v8::Isolate* isolate, v8::Local label); virtual void consoleTimeStamp(v8::Isolate* isolate, v8::Local label); We don't want to use rtti so we locally modified v8-inspector.h to provide an empty implementation for these functions to get around the problem, which worked fine, but, obviously we don't want to do that forever. Is there another way around this? Should we submit a change to add default implementations for these functions or will someone else pick this up? -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/f8b90b9f-f5ac-4115-b37f-c108d99464c8n%40googlegroups.com.
[v8-users] Re: Problem linking when implementing V8InspectorClient
FWIW, I rebuilt V8 after I made the above change to v8-inspector.h and discovered that, in fact, there are default implementations of consoleTime and friends in v8-inspector-impl.cc which, of course, doesn't play nicely with my change to v8-inspector.h but does suggest that there was an intent to have a default implementation for these functions. So just wondering if these can be moved to v8-inspector.h as that tells the compiler not to produce the typeinfo reference for v8_inspector::V8InspectorClient. Is it reasonable to submit a PR to make this change? Sorry to be so pushy, but this is a bit of a hassle for us, currently. Thanks On Thursday, September 26, 2024 at 12:25:53 PM UTC-4 alex...@gmail.com wrote: > We have code that implements v8_inspector::V8InspectorClient and when we > upgraded to V8 13.1.36 (thought he problem looks like it's there up to > 13.1.99) we get the following when we try to link: > > ld64.lld: error: undefined symbol: typeinfo for > v8_inspector::V8InspectorClient > >>> referenced by /Users/imagine/src/inspector.cc > >>> out/arm64.mac.release/obj/inspector.o:(symbol typeinfo for > imagine::InspectorClient+0x10) > >>> did you mean: vtable for v8_inspector::V8InspectorClient > >>> defined in: > v8/out/arm64.mac.release/obj/libv8_monolith.a(v8-inspector-impl.o) > clang++: error: linker command failed with exit code 1 (use -v to see > invocation) > > This seems to be because the following newish virtual functions in the > base class have no default implementation: > > virtual void consoleTime(v8::Isolate* isolate, v8::Local > label); > virtual void consoleTimeEnd(v8::Isolate* isolate, > v8::Local label); > virtual void consoleTimeStamp(v8::Isolate* isolate, > v8::Local label); > > We don't want to use rtti so we locally modified v8-inspector.h to provide > an empty implementation for these functions to get around the problem, > which worked fine, but, obviously we don't want to do that forever. > > Is there another way around this? Should we submit a change to add default > implementations for these functions or will someone else pick this up? > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/0aa02cd6-a5eb-45da-b1e7-b68d27badcdan%40googlegroups.com.
Re: [v8-users] Re: Problem linking when implementing V8InspectorClient
Thanks Jakob and Benedikt! Will do. On Monday, September 30, 2024 at 7:44:40 AM UTC-4 Jakob Kummerow wrote: > Benedikt says off-list that he doesn't have an opinion: moving the empty > implementations into v8-inspector.h is fine. > > Feel free to upload a patch. > > > On Mon, Sep 30, 2024 at 10:42 AM Jakob Kummerow > wrote: > >> +Benedikt Meurer who made these changes and might have an opinion. >> >> >> On Sun, Sep 29, 2024 at 12:55 PM alex...@gmail.com >> wrote: >> >>> FWIW, I rebuilt V8 after I made the above change to v8-inspector.h and >>> discovered that, in fact, there are default implementations of consoleTime >>> and friends in v8-inspector-impl.cc which, of course, doesn't play nicely >>> with my change to v8-inspector.h but does suggest that there was an intent >>> to have a default implementation for these functions. So just wondering if >>> these can be moved to v8-inspector.h as that tells the compiler not to >>> produce the typeinfo reference for v8_inspector::V8InspectorClient. >>> >>> Is it reasonable to submit a PR to make this change? Sorry to be so >>> pushy, but this is a bit of a hassle for us, currently. >>> >>> Thanks >>> >>> On Thursday, September 26, 2024 at 12:25:53 PM UTC-4 alex...@gmail.com >>> wrote: >>> >>>> We have code that implements v8_inspector::V8InspectorClient and when >>>> we upgraded to V8 13.1.36 (thought he problem looks like it's there up to >>>> 13.1.99) we get the following when we try to link: >>>> >>>> ld64.lld: error: undefined symbol: typeinfo for >>>> v8_inspector::V8InspectorClient >>>> >>> referenced by /Users/imagine/src/inspector.cc >>>> >>> out/arm64.mac.release/obj/inspector.o:(symbol typeinfo for >>>> imagine::InspectorClient+0x10) >>>> >>> did you mean: vtable for v8_inspector::V8InspectorClient >>>> >>> defined in: >>>> v8/out/arm64.mac.release/obj/libv8_monolith.a(v8-inspector-impl.o) >>>> clang++: error: linker command failed with exit code 1 (use -v to see >>>> invocation) >>>> >>>> This seems to be because the following newish virtual functions in the >>>> base class have no default implementation: >>>> >>>> virtual void consoleTime(v8::Isolate* isolate, v8::Local >>>> label); >>>> virtual void consoleTimeEnd(v8::Isolate* isolate, >>>> v8::Local label); >>>> virtual void consoleTimeStamp(v8::Isolate* isolate, >>>> v8::Local label); >>>> >>>> We don't want to use rtti so we locally modified v8-inspector.h to >>>> provide an empty implementation for these functions to get around the >>>> problem, which worked fine, but, obviously we don't want to do that >>>> forever. >>>> >>>> Is there another way around this? Should we submit a change to add >>>> default implementations for these functions or will someone else pick this >>>> up? >>>> >>> -- >>> >> >> > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/abdd57b7-1ead-403d-9200-6228a09cf0d6n%40googlegroups.com.
Re: [v8-users] When is an internal field destroyed?
To flesh out Ben's answer a bit, you'd want a Persistent reference to obj which you could SetWeak. I guess maybe that's obvious but never hurts to state the obvious. The Persistent reference could be inside Point or a base class of Point (and others) if you have a menagerie of object types to manage. If you're concerned about the non-deterministic nature of the cleanup that Ben pointed out, you can make Point (and any other such objects) extend String::ExternalStringResource. Heap tear down will call Dispose for every ExternalString in the Isolate. In addition, if obj is collected, and the presumed only reference to p (the interal field) is eliminated, the ExternalString will be collected and Dispose called for p. If all you want Dispose to do is delete p, you don't have to specify a Dispose override. It might have been nice if V8 had a similar mechanism for plain External objects as it's a bit weird having your objects extend ExternalStringResource but on the grand scheme of weird it's not a big deal. Note that the determistic aspect of String::ExternalStringResource is only really important if your process creates and destroys multiple isolates as a matter of course so you don't want to wait for process termination to clean everything up. Have fun! On Monday, April 19, 2021 at 8:46:33 AM UTC-5 Ben Noordhuis wrote: > On Sun, Apr 18, 2021 at 8:13 PM Richard wrote: > > > > In the following sample code from: > https://v8.dev/docs/embed#accessing-dynamic-variables > > > > Point* p = ...; > > v8::Local obj = point_templ->NewInstance(); > > obj->SetInternalField(0, v8::External::New(isolate, p)); > > > > Is there a way to know when `p` has been finished with? I would like to > know when/how to delete the allocated memory. > > See v8::Global::SetWeak(), it lets you register a callback that's > invoked when the object is reclaimed by the garbage collector. > > Caveat emptor, garbage collection is non-deterministic; it might > simply never run with short-lived scripts. > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/d1c2b401-dabe-4239-90f4-9926d14bbfd8n%40googlegroups.com.
[v8-users] Re: a question about Isolate RequestInterrupt
I think it means that JavaScript code should not be called and maybe even messing with data in the heap is a bad idea. Not sure about the latter. I think the heap and JS stack are in indeterminate or at least intermediate states that wouldn't tolerate interlopers when you enter the callback so running JS code from there is a bad idea. It looks like you probably could invoke RequestInterrupt inside the callback though that seems like a bit of an oddball thing to do. HTH On Wednesday, January 12, 2022 at 12:00:46 PM UTC-6 anar...@gmail.com wrote: > hi, i have a question about Isolate RequestInterrupt API. what do the > "Registered > |callback| must not reenter interrupted Isolate." mean? can i call > RequestInterrupt > again in RequestInterrupt callback. I think it is ok. And i find some code > in v8 source code. > [image: 飞书20220113-015705.png] > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/c747cacd-a186-4f6a-bf45-4817a5419055n%40googlegroups.com.
Re: [v8-users] Problem with ScopeInfo when used codeCache
Victor, thanks for the quick response. I had
created https://issues.chromium.org/issues/409512701 though I don't see how
I can assign it to your or anyone else. Maybe I can't?
As far as a repro goes, I can easily reproduce with my executable but my
company would not want me to send it to you :-( (nothing personal) so I'm
going to have to put together a more standalone test. I'll have to figure
out how to make and then load/run a snapshot, I guess, something I've never
done before. Or maybe I can leverage some of the V8 unit tests. Regardless,
this might take a bit of time.
On Wednesday, April 9, 2025 at 5:52:49 PM UTC-4 victo...@google.com wrote:
> Thanks for the email, alexkodat.
>
> It seems to be a bug when rehashing the table after code cache. Do you
> have a repro?
> Could you please file a bug in https://issues.chromium.org component
> "Chromium > Blink > JavaScript > Runtime" and assign it to me.
>
> Thanks,
> - Victor
>
> On Wed, Apr 9, 2025 at 6:14 AM alex...@gmail.com
> wrote:
>
>> Hey folks,
>>
>> I have a class with many private functions/properties (77 in the most
>> recent incarnation). When I get a stack trace (say to create an Error
>> object) when I'm inside a function in this class, we end up in
>> ClassScope::ClassScope in scopes.cc:
>> ```
>> if (scope_info->HasSavedClassVariable()) {
>> Tagged name;
>> int index;
>> std::tie(name, index) = scope_info->SavedClassVariable();
>> ```
>>
>> This ends up loading an index tacked on to the end of the context slots
>> in the ScopeInfo heap object which looks like:
>>
>> ```
>> 0x25eabdda3541: [ScopeInfo]
>> - map: 0x2ad145840d71
>> - parameters: 0
>> - context locals : 79
>> - local names in a hashtable: 0x25eabdda2d19 > (NAME_TO_INDEX_HASH_TABLE_TYPE)>
>> - scope type: CLASS_SCOPE
>> - language mode: strict
>> - class scope has private brand
>> - has saved class variable
>> - function kind: NormalFunction
>> - outer scope info: 0x25eabdda2801
>> - start position: 22541
>> - end position: 282321
>> - length: 87
>> - context slots {
>> - 51: 0x1a45b21b8311
>> - 72: 0x1a45b21b7fc9
>> - 0: 0x1a45b21b6d21
>> - 32: 0x1a45b21b71d1
>> - 75: 0x1a45b21b9e59
>> - 77: 0x2ad145846ae1
>> - 59: 0x1070007a8419
>> - 29: 0x1a45b21b70a1
>> - 37: 0x1a45b21b84a9
>> - 71: 0x1a45b21bcc91
>> - 17: 0x1a45b21b6f69
>> - 28: 0x1a45b21b7081
>> - 27: 0x1a45b21b7061
>> - 39: 0x1a45b21b8a31
>> - 45: 0x1a45b21b91c1
>> - 8: 0x1a45b21b6df9
>> - 44: 0x1a45b21b9d91
>> - 66: 0x1a45b21bd609
>> - 78: 0x208cca45af99
>> ```
>> A lot more slots follow, but after them is the class variable info
>> retrieved by the TorqueGeneratedScopeInfo::saved_class_variable_info
>> function. FWIW, job in lldb does not show the value (23 in my example).
>>
>> That saved_class_variable_info is then used to index a name and value in
>> the local names hash table referenced by the ScopeInfo heap object. And
>> this table is used in ScopeInfo::SavedClassVariable to get the class name
>> and index:
>> ```
>> if (HasInlinedLocalNames()) {
>> ...
>> } else {
>> // The saved class variable info corresponds to the offset in the hash
>> // table storage.
>> InternalIndex entry(saved_class_variable_info());
>> Tagged table = context_local_names_hashtable();
>> Tagged name = table->KeyAt(entry);
>> DCHECK(IsString(name));
>> return std::make_pair(Cast(name), table->IndexAt(entry));
>> }
>> ```
>> The table is a hash table because it's gotten beyond a certain size. In
>> my example it looks like:
>> ```
>> 0x25eabdda2d19: [NameToIndexHashTable]
>> - FixedArray length: 259
>> - elements: 79
>> - deleted: 0
>> - capacity: 12
>> - elements: {
>> 0: #getTransactionId -> 51
>> 1: #valueMatches -> 72
>> 4: #allowRunJsScript -> 0
>> 5: #call -> 32
>> 6: #writeNumericParm -> 75
>> 7: .brand -> 77
>> 9: #sendResponse -> 59
>> 10: #timeZone -> 29
>> 11: #createFind -> 37
>> 12: #updateRecords -> 71
>> 13: #pendingImageFields -> 17
>> 14: #syncSemaphore -> 28
>> 15: #syncQueueLock -> 27
>> 16: #find -> 39
>>
[v8-users] Problem with ScopeInfo when used codeCache
Hey folks,
I have a class with many private functions/properties (77 in the most
recent incarnation). When I get a stack trace (say to create an Error
object) when I'm inside a function in this class, we end up in
ClassScope::ClassScope in scopes.cc:
```
if (scope_info->HasSavedClassVariable()) {
Tagged name;
int index;
std::tie(name, index) = scope_info->SavedClassVariable();
```
This ends up loading an index tacked on to the end of the context slots in
the ScopeInfo heap object which looks like:
```
0x25eabdda3541: [ScopeInfo]
- map: 0x2ad145840d71
- parameters: 0
- context locals : 79
- local names in a hashtable: 0x25eabdda2d19
- scope type: CLASS_SCOPE
- language mode: strict
- class scope has private brand
- has saved class variable
- function kind: NormalFunction
- outer scope info: 0x25eabdda2801
- start position: 22541
- end position: 282321
- length: 87
- context slots {
- 51: 0x1a45b21b8311
- 72: 0x1a45b21b7fc9
- 0: 0x1a45b21b6d21
- 32: 0x1a45b21b71d1
- 75: 0x1a45b21b9e59
- 77: 0x2ad145846ae1
- 59: 0x1070007a8419
- 29: 0x1a45b21b70a1
- 37: 0x1a45b21b84a9
- 71: 0x1a45b21bcc91
- 17: 0x1a45b21b6f69
- 28: 0x1a45b21b7081
- 27: 0x1a45b21b7061
- 39: 0x1a45b21b8a31
- 45: 0x1a45b21b91c1
- 8: 0x1a45b21b6df9
- 44: 0x1a45b21b9d91
- 66: 0x1a45b21bd609
- 78: 0x208cca45af99
```
A lot more slots follow, but after them is the class variable info
retrieved by the TorqueGeneratedScopeInfo::saved_class_variable_info
function. FWIW, job in lldb does not show the value (23 in my example).
That saved_class_variable_info is then used to index a name and value in
the local names hash table referenced by the ScopeInfo heap object. And
this table is used in ScopeInfo::SavedClassVariable to get the class name
and index:
```
if (HasInlinedLocalNames()) {
...
} else {
// The saved class variable info corresponds to the offset in the hash
// table storage.
InternalIndex entry(saved_class_variable_info());
Tagged table = context_local_names_hashtable();
Tagged name = table->KeyAt(entry);
DCHECK(IsString(name));
return std::make_pair(Cast(name), table->IndexAt(entry));
}
```
The table is a hash table because it's gotten beyond a certain size. In my
example it looks like:
```
0x25eabdda2d19: [NameToIndexHashTable]
- FixedArray length: 259
- elements: 79
- deleted: 0
- capacity: 12
- elements: {
0: #getTransactionId -> 51
1: #valueMatches -> 72
4: #allowRunJsScript -> 0
5: #call -> 32
6: #writeNumericParm -> 75
7: .brand -> 77
9: #sendResponse -> 59
10: #timeZone -> 29
11: #createFind -> 37
12: #updateRecords -> 71
13: #pendingImageFields -> 17
14: #syncSemaphore -> 28
15: #syncQueueLock -> 27
16: #find -> 39
17: #getFindRecordTypeInfoSet -> 45
18: #inBuffer -> 8
20: #getFileInfo -> 44
21: #syncBuildRecord -> 66
23: Connection -> 78
```
As noted before, the saved_class_variable_info has value 23 which does,
indeed, reference Connection, my class name.
The problem occurs when I use the codeCache from the compilation on the
Isolate shown above on a different Isolate. The ScopeInfo heap object looks
largely identical to the first Isolate, but the local names hash table
looks like it's been rehashed (unsurprisingly):
```
0x27b95eb86f19: [NameToIndexHashTable]
- FixedArray length: 259
- elements: 79
- deleted: 0
- capacity: 128
- elements: {
0: #getTransactionId -> 51
1: #valueMatches -> 72
4: #allowRunJsScript -> 0
5: #call -> 32
6: #writeNumericParm -> 75
7: .brand -> 77
9: #sendResponse -> 59
10: #timeZone -> 29
11: #createFind -> 37
12: #updateRecords -> 71
13: #pendingImageFields -> 17
14: #syncSemaphore -> 28
15: #syncQueueLock -> 27
16: #find -> 39
17: Connection -> 78
18: #inBuffer -> 8
19: #getFindRecordTypeInfoSet -> 45
20: #getUpdateValue -> 49
21: #syncBuildRecord -> 66
24: #syncImagineFileObj -> 24
```
Note that the class name Connection is now in slot 17 and slot 23 is
unused. So now, when we try to create the class ScopeInfo for a stack
trace, the 23 in saved_class_variable_info references an unused slot and I
get a seg fault or a failed DCHECK(isString(name)), depending on the type
of build.
Unfortunately, the fix seems beyond my meager skills. It seems that in
deserialization for ScopeInfo, we would have to detect that we have a
saved_class_variable_info and so need to recalculate
saved_class_variable_info from the old value and the new hash table. But
I'm not sure we can control the order i
[v8-users] Re: Problem with ScopeInfo when used codeCache
FWIW, one "thought" I had on this was that if saved_class_variable_info
were an Smi if the local names are inlined and a String reference, if not,
then there would never be a need to fix anything up during deserialization
as the String reference could be used to do a lookup in the local names
hash table. But this is just kibitzing.
On Wednesday, April 9, 2025 at 12:14:53 AM UTC-4 alex...@gmail.com wrote:
> Hey folks,
>
> I have a class with many private functions/properties (77 in the most
> recent incarnation). When I get a stack trace (say to create an Error
> object) when I'm inside a function in this class, we end up in
> ClassScope::ClassScope in scopes.cc:
> ```
> if (scope_info->HasSavedClassVariable()) {
> Tagged name;
> int index;
> std::tie(name, index) = scope_info->SavedClassVariable();
> ```
>
> This ends up loading an index tacked on to the end of the context slots in
> the ScopeInfo heap object which looks like:
>
> ```
> 0x25eabdda3541: [ScopeInfo]
> - map: 0x2ad145840d71
> - parameters: 0
> - context locals : 79
> - local names in a hashtable: 0x25eabdda2d19 (NAME_TO_INDEX_HASH_TABLE_TYPE)>
> - scope type: CLASS_SCOPE
> - language mode: strict
> - class scope has private brand
> - has saved class variable
> - function kind: NormalFunction
> - outer scope info: 0x25eabdda2801
> - start position: 22541
> - end position: 282321
> - length: 87
> - context slots {
> - 51: 0x1a45b21b8311
> - 72: 0x1a45b21b7fc9
> - 0: 0x1a45b21b6d21
> - 32: 0x1a45b21b71d1
> - 75: 0x1a45b21b9e59
> - 77: 0x2ad145846ae1
> - 59: 0x1070007a8419
> - 29: 0x1a45b21b70a1
> - 37: 0x1a45b21b84a9
> - 71: 0x1a45b21bcc91
> - 17: 0x1a45b21b6f69
> - 28: 0x1a45b21b7081
> - 27: 0x1a45b21b7061
> - 39: 0x1a45b21b8a31
> - 45: 0x1a45b21b91c1
> - 8: 0x1a45b21b6df9
> - 44: 0x1a45b21b9d91
> - 66: 0x1a45b21bd609
> - 78: 0x208cca45af99
> ```
> A lot more slots follow, but after them is the class variable info
> retrieved by the TorqueGeneratedScopeInfo::saved_class_variable_info
> function. FWIW, job in lldb does not show the value (23 in my example).
>
> That saved_class_variable_info is then used to index a name and value in
> the local names hash table referenced by the ScopeInfo heap object. And
> this table is used in ScopeInfo::SavedClassVariable to get the class name
> and index:
> ```
> if (HasInlinedLocalNames()) {
> ...
> } else {
> // The saved class variable info corresponds to the offset in the hash
> // table storage.
> InternalIndex entry(saved_class_variable_info());
> Tagged table = context_local_names_hashtable();
> Tagged name = table->KeyAt(entry);
> DCHECK(IsString(name));
> return std::make_pair(Cast(name), table->IndexAt(entry));
> }
> ```
> The table is a hash table because it's gotten beyond a certain size. In my
> example it looks like:
> ```
> 0x25eabdda2d19: [NameToIndexHashTable]
> - FixedArray length: 259
> - elements: 79
> - deleted: 0
> - capacity: 12
> - elements: {
> 0: #getTransactionId -> 51
> 1: #valueMatches -> 72
> 4: #allowRunJsScript -> 0
> 5: #call -> 32
> 6: #writeNumericParm -> 75
> 7: .brand -> 77
> 9: #sendResponse -> 59
> 10: #timeZone -> 29
> 11: #createFind -> 37
> 12: #updateRecords -> 71
> 13: #pendingImageFields -> 17
> 14: #syncSemaphore -> 28
> 15: #syncQueueLock -> 27
> 16: #find -> 39
> 17: #getFindRecordTypeInfoSet -> 45
> 18: #inBuffer -> 8
> 20: #getFileInfo -> 44
> 21: #syncBuildRecord -> 66
> 23: Connection -> 78
> ```
> As noted before, the saved_class_variable_info has value 23 which does,
> indeed, reference Connection, my class name.
>
> The problem occurs when I use the codeCache from the compilation on the
> Isolate shown above on a different Isolate. The ScopeInfo heap object looks
> largely identical to the first Isolate, but the local names hash table
> looks like it's been rehashed (unsurprisingly):
> ```
> 0x27b95eb86f19: [NameToIndexHashTable]
> - FixedArray length: 259
> - elements: 79
> - deleted: 0
> - capacity: 128
> - elements: {
> 0: #getTransactionId -> 51
> 1: #valueMatches -> 72
> 4: #allowRunJsScript -> 0
> 5: #call -> 32
> 6: #writeNumericParm -> 75
&g
Re: [v8-users] Re: Problem with ScopeInfo when used codeCache
Thanks Toon, will do.
On Wednesday, April 9, 2025 at 7:52:48 AM UTC-4 Toon Verwaest wrote:
> Thanks for this report! That sounds like a ScopeInfo deserialization bug.
> Presumably we rehash when we deserialize the NameToIndexHashTable but
> forget that we directly point to an entry from the ScopeInfo. Care to file
> a bug?
>
> On Wed, Apr 9, 2025 at 1:32 PM alex...@gmail.com
> wrote:
>
>> FWIW, one "thought" I had on this was that if saved_class_variable_info
>> were an Smi if the local names are inlined and a String reference, if not,
>> then there would never be a need to fix anything up during deserialization
>> as the String reference could be used to do a lookup in the local names
>> hash table. But this is just kibitzing.
>>
>> On Wednesday, April 9, 2025 at 12:14:53 AM UTC-4 alex...@gmail.com wrote:
>>
>>> Hey folks,
>>>
>>> I have a class with many private functions/properties (77 in the most
>>> recent incarnation). When I get a stack trace (say to create an Error
>>> object) when I'm inside a function in this class, we end up in
>>> ClassScope::ClassScope in scopes.cc:
>>> ```
>>> if (scope_info->HasSavedClassVariable()) {
>>> Tagged name;
>>> int index;
>>> std::tie(name, index) = scope_info->SavedClassVariable();
>>> ```
>>>
>>> This ends up loading an index tacked on to the end of the context slots
>>> in the ScopeInfo heap object which looks like:
>>>
>>> ```
>>> 0x25eabdda3541: [ScopeInfo]
>>> - map: 0x2ad145840d71
>>> - parameters: 0
>>> - context locals : 79
>>> - local names in a hashtable: 0x25eabdda2d19 >> (NAME_TO_INDEX_HASH_TABLE_TYPE)>
>>> - scope type: CLASS_SCOPE
>>> - language mode: strict
>>> - class scope has private brand
>>> - has saved class variable
>>> - function kind: NormalFunction
>>> - outer scope info: 0x25eabdda2801
>>> - start position: 22541
>>> - end position: 282321
>>> - length: 87
>>> - context slots {
>>> - 51: 0x1a45b21b8311
>>> - 72: 0x1a45b21b7fc9
>>> - 0: 0x1a45b21b6d21
>>> - 32: 0x1a45b21b71d1
>>> - 75: 0x1a45b21b9e59
>>> - 77: 0x2ad145846ae1
>>> - 59: 0x1070007a8419
>>> - 29: 0x1a45b21b70a1
>>> - 37: 0x1a45b21b84a9
>>> - 71: 0x1a45b21bcc91
>>> - 17: 0x1a45b21b6f69
>>> - 28: 0x1a45b21b7081
>>> - 27: 0x1a45b21b7061
>>> - 39: 0x1a45b21b8a31
>>> - 45: 0x1a45b21b91c1
>>> - 8: 0x1a45b21b6df9
>>> - 44: 0x1a45b21b9d91
>>> - 66: 0x1a45b21bd609
>>> - 78: 0x208cca45af99
>>> ```
>>> A lot more slots follow, but after them is the class variable info
>>> retrieved by the TorqueGeneratedScopeInfo::saved_class_variable_info
>>> function. FWIW, job in lldb does not show the value (23 in my example).
>>>
>>> That saved_class_variable_info is then used to index a name and value in
>>> the local names hash table referenced by the ScopeInfo heap object. And
>>> this table is used in ScopeInfo::SavedClassVariable to get the class name
>>> and index:
>>> ```
>>> if (HasInlinedLocalNames()) {
>>> ...
>>> } else {
>>> // The saved class variable info corresponds to the offset in the
>>> hash
>>> // table storage.
>>> InternalIndex entry(saved_class_variable_info());
>>> Tagged table = context_local_names_hashtable();
>>> Tagged name = table->KeyAt(entry);
>>> DCHECK(IsString(name));
>>> return std::make_pair(Cast(name), table->IndexAt(entry));
>>> }
>>> ```
>>> The table is a hash table because it's gotten beyond a certain size. In
>>> my example it looks like:
>>> ```
>>> 0x25eabdda2d19: [NameToIndexHashTable]
>>> - FixedArray length: 259
>>> - elements: 79
>>> - deleted: 0
>>> - capacity: 12
>>> - elements: {
>>> 0: #getTransactionId -> 51
>>> 1: #valueMatches -> 72
>>> 4: #allowRunJsScript -> 0
>>> 5: #call -> 32
>>> 6: #writeNumericParm -> 75
>>> 7: .brand -> 77
>>> 9: #sendResponse -> 59
>>> 10: #timeZone -> 29
>>> 11: #createFind -> 37
>>> 12: #updateRecords -> 7
