eliassjogreen
LightNews LightNews
banner
xn--sjgreen-b1a.se
eliassjogreen
@xn--sjgreen-b1a.se
100 followers 230 following 27 posts
Mörda bilar
Hata data
Posts Replies Media Videos
xn--sjgreen-b1a.se
The string it creates seems to be truncated and rounded to around ~32 chars when dealing with radix 3, but the bug exists for all radixes which aren't a power of 2. This makes sense because v8 doesn't use the faulty `DoubleToRadixStringView` when stringifying 2, 4, 8, 16 and 32.
> BigInt(Number.MAX_VALUE).toString(3); '10020200012020012100112000100111021022122212222001221000102201022211210002220120012001210100102121221010102121102012120122212101021201002210000120200221010111201212212100102000000110211220011000211001111011101122010121200202000122010201101100202212110210010010212102001122222220120021022210121002121000012121020221100222012001202111200021110200022201110212120110022120102101120220021102200001222201010202111212222012100102020202121100222110021110221122012020010020002101021002200211100222220102010110112202221110012220210110201122101201000222101001001022220122101120121201002101221011001102020220211200122211111202210111221021101122010102210200202' > Number.MAX_VALUE.toString(3); '10020200012020012100112000100111212000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' > BigInt(Number.MAX_VALUE).toString(3).substring(0, 32) === Number.MAX_VALUE.toString(3).substring(0, 32); true > for (let i = 2; i <= 36; i++) console.log(`${i}: ${BigInt(Number.MAX_VALUE).toString(i) === Number.MAX_VALUE.toString(i)}`); 2: true 3: false 4: true 5: false 6: false 7: false 8: true 9: false 10: false 11: false 12: false 13: false 14: false 15: false 16: true 17: false 18: false 19: false 20: false 21: false 22: false 23: false 24: false 25: false 26: false 27: false 28: false 29: false 30: false 31: false 32: true 33: false 34: false 35: false 36: false
April 24, 2025 at 10:02 PM
xn--sjgreen-b1a.se
We found a bug in v8 while developing the @trynova.dev JavaScript engine. I was implementing the Number.prototype.toString method when @aapoalas.trynova.dev found that v8 doesn't properly handle Number.MAX_VALUE.toString()!
> BigInt(Number.MAX_VALUE).toString(3) === Number.MAX_VALUE.toString(3); false
April 24, 2025 at 9:32 PM
xn--sjgreen-b1a.se
The major problem of course is my rather simple and stupid algorithm which could be heavily optimized but it's still quite fast in all other modern and optimized JS engines. I also can't find any single major performance bottleneck engine-wise like I did for day 4 when profiling though.
A callstack generated from the profiling of the execution. Shown are the most called symbols ordered descending.
December 5, 2024 at 10:19 PM
xn--sjgreen-b1a.se
Profiling the run 97% of the calls are just resolving and checking if bindings exist in the environment. Something which could be greatly sped up by some rather simple caching.
A table of the five most called symbols where 87% of calls are for a symbol named "has_binding" and 10% are for a symbol named "resolve_binding". The last three symbols are "execute_instruction", "get_instruction" and "inner_execute": all three of which combined take less than a 1% of calls.
December 5, 2024 at 8:45 PM
xn--sjgreen-b1a.se
My computer got a bit too hot when running the test262 suite for Nova last night 😅

#javascript
A 2019 MacBook Pro 16" sitting outside on my balcony on a stool in the snow. On the display a terminal running the Nova test262 runner.
November 22, 2024 at 8:01 AM