NameClient usage

[Kouhei Ueno]

Hi platform-architecture-dev,

cc: sase...@microsoft.com where this came up in a code review.

I'd like to check if I understand the NameClient correctly.

My understanding is that:

- NameClient should be inherited near the root of the inheritance graph.

-- Otherwise Member<BaseClass> -> NameTrait<BaseClass> fails to attribute the instance correctly.

- They are only needed for classes which:

-- the class instances themselves will consume a considerable amount of memory (or is this the ref graph stemming from the class instances will consume a considerable amount of memory?)

-- a web developer can understand and it is actionable for a web developer to reduce memory size when they see it is on fire

Is my understanding correct? Do you mind if I put this as a class comment?

Thanks, 

kouhei

[Kentaro Hara]

On Wed, Jul 3, 2019 at 12:43 PM Kouhei Ueno <kou...@google.com> wrote:

Hi platform-architecture-dev,

cc: sase...@microsoft.com where this came up in a code review.

I'd like to check if I understand the NameClient correctly.

My understanding is that:

- NameClient should be inherited near the root of the inheritance graph.

-- Otherwise Member<BaseClass> -> NameTrait<BaseClass> fails to attribute the instance correctly.

Right.

 

- They are only needed for classes which:

-- the class instances themselves will consume a considerable amount of memory (or is this the ref graph stemming from the class instances will consume a considerable amount of memory?)

-- a web developer can understand and it is actionable for a web developer to reduce memory size when they see it is on fire

NameClients are needed for classes that should explicitly appear in the heap snapshot of the dev tools (i.e., when the information is useful for web developers).

Is my understanding correct? Do you mind if I put this as a class comment?

Thanks, 

kouhei

--

Kentaro Hara, Tokyo, Japan

[Kouhei Ueno]

Thanks

On Wed, Jul 3, 2019 at 2:29 PM Kentaro Hara <har...@google.com> wrote:

On Wed, Jul 3, 2019 at 12:43 PM Kouhei Ueno <kou...@google.com> wrote:

Hi platform-architecture-dev,

cc: sase...@microsoft.com where this came up in a code review.

I'd like to check if I understand the NameClient correctly.

My understanding is that:

- NameClient should be inherited near the root of the inheritance graph.

-- Otherwise Member<BaseClass> -> NameTrait<BaseClass> fails to attribute the instance correctly.

Right.

 

- They are only needed for classes which:

-- the class instances themselves will consume a considerable amount of memory (or is this the ref graph stemming from the class instances will consume a considerable amount of memory?)

Do you happen to know which of the two here is correct?

 

-- a web developer can understand and it is actionable for a web developer to reduce memory size when they see it is on fire

NameClients are needed for classes that should explicitly appear in the heap snapshot of the dev tools (i.e., when the information is useful for web developers).

Is my understanding correct? Do you mind if I put this as a class comment?

Thanks, 

kouhei

--

Kentaro Hara, Tokyo, Japan

--

kouhei

[Kentaro Hara]

On Wed, Jul 3, 2019 at 2:32 PM Kouhei Ueno <kou...@google.com> wrote:

Thanks

On Wed, Jul 3, 2019 at 2:29 PM Kentaro Hara <har...@google.com> wrote:

On Wed, Jul 3, 2019 at 12:43 PM Kouhei Ueno <kou...@google.com> wrote:

Hi platform-architecture-dev,

cc: sase...@microsoft.com where this came up in a code review.

I'd like to check if I understand the NameClient correctly.

My understanding is that:

- NameClient should be inherited near the root of the inheritance graph.

-- Otherwise Member<BaseClass> -> NameTrait<BaseClass> fails to attribute the instance correctly.

Right.

 

- They are only needed for classes which:

-- the class instances themselves will consume a considerable amount of memory (or is this the ref graph stemming from the class instances will consume a considerable amount of memory?)

Do you happen to know which of the two here is correct?

I'd say:

- The class is likely to be in a ref chain that is likely to hold a considerable amount of memory.

- The class is something web developers care about.

 

-- a web developer can understand and it is actionable for a web developer to reduce memory size when they see it is on fire

NameClients are needed for classes that should explicitly appear in the heap snapshot of the dev tools (i.e., when the information is useful for web developers).

Is my understanding correct? Do you mind if I put this as a class comment?

Thanks, 

kouhei

--

Kentaro Hara, Tokyo, Japan

--

kouhei

[Michael Lippautz]

On Wed, Jul 3, 2019 at 7:44 AM Kentaro Hara <har...@google.com> wrote:

On Wed, Jul 3, 2019 at 2:32 PM Kouhei Ueno <kou...@google.com> wrote:

Thanks

On Wed, Jul 3, 2019 at 2:29 PM Kentaro Hara <har...@google.com> wrote:

On Wed, Jul 3, 2019 at 12:43 PM Kouhei Ueno <kou...@google.com> wrote:

Hi platform-architecture-dev,

cc: sase...@microsoft.com where this came up in a code review.

I'd like to check if I understand the NameClient correctly.

My understanding is that:

- NameClient should be inherited near the root of the inheritance graph.

-- Otherwise Member<BaseClass> -> NameTrait<BaseClass> fails to attribute the instance correctly.

Right.

 

- They are only needed for classes which:

-- the class instances themselves will consume a considerable amount of memory (or is this the ref graph stemming from the class instances will consume a considerable amount of memory?)

Do you happen to know which of the two here is correct?

I'd say:

- The class is likely to be in a ref chain that is likely to hold a considerable amount of memory.

- The class is something web developers care about.

+1

Ad.:

- The name is mostly useful for DevTools and debugging the web platform itself.

- Everything that is exposed to JS via ScriptWrappable automatically gets a name from the JS prototype.

- Additionally everything that could be interesting for web developers should get a name as well. 

If it's internal and performance critical (e.g. no vtables), we intentionally left out the name, resulting in something like "InternalNode" in the retainer chain in DevTools. This is a compromise.

[Kouhei Ueno]

Thank you for your insights! I'll add them as a class comment later.

--

kouhei