Creating 2 CFunction overloads with same argument count fails

[Yagiz Nizipli]

Currently it is not possible to have 2 different CFunction overloads with same number of arguments that have different types, but in certain scenarios, such as for strings, it's beneficial to have multiple overloads, due to performance.

If we encounter this, it fails due to the following assertion:

v8/src/api/api.cc:1181; message = Check failed: c_function_overloads.data()[i].ArgumentCount() != c_function_overloads.data()[j].ArgumentCount() (1 vs. 1).

For example having 2 CFunction overloads for a method that receives a string parameter, is beneficial for having a faster access for v8::FastOneByteString, without regressing on one of those cases.

method(v8::Local<v8::Object> receiver, v8::Local<v8::Value> myString);

method(v8::Local<v8::Object> receiver, const v8::FastOneByteString& myString);

[Andreas Haas]

Hi,

When you allow function overloads, you have to think about how you can do the overload resolution, i.e. how you can decide which function overload should be called. Using the argument count for function overload resolution allows us to do overload resolution during compile time. The generated code knows exactly which CFunction it will call, and will therefore be as fast as possible.

If multiple CFunctions with the same argument count are allowed, then overload resolution has to happen during runtime, which means runtime overhead and less performance.

Additionally this would introduce quite some complexity to the compiler, in an area that is hard to test with fuzzers.

In can think of two approaches that are probably better in most cases:

1) Have two API functions with different names in JavaScript, e.g. `methodForString()` and `methodForObject()`. Then the JavaScript code can do the overload resolution, and may be able to use application logic to optimize it away.

2) Since the CFunction with the `Local<Value>` parameter is probably the slow path anyways, you may just handle it with regular API calls. With only parameters of type `Local<Value>`, regular API calls are barely slower than fast API calls. Aside from micro benchmarks, you can probably not see a difference.

To be honest, I think it would be better to deprecate `FastOneByteString`, as this is the one configuration of the fast API that still does not allow GCs. Unfortunately even with an optimization like https://crrev.com/c/6011904, `FastOneByteString` is faster.

Cheers, Andreas

--
--
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/5cb28ca1-859b-4b52-97bf-2fdd6a42aed4n%40googlegroups.com.

--

Andreas Haas

Software Engineer

ah...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

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.

[Yagiz Nizipli]

Thanks for the reply Andreas. I've reached out to devsnek about reviving https://chromium-review.googlesource.com/c/v8/v8/+/6011904. I'll open a CR soon.