test: increase change_in_bytes for napi_adjust_external_memory test

[190n]

JavaScriptCore ignores small deltas in its interface for reporting external memory:

https://github.com/WebKit/WebKit/blob/8bbba2aa777cf326e24a4e5c63b1f51bd52315ff/Source/JavaScriptCore/heap/HeapInlines.h#L213-L229

More broadly, it seem reasonable for any other JS engine to do the same. Passing a large change ensures that the change is actually applied and the new adjusted value will be greater than zero (otherwise, the test relies on some external memory previously being reported as allocated). In turn, this makes the test more applicable to non-V8 implementations of Node-API.

[anonrig]

Can you be more specific? What is the constraint you're seeing?

[190n]

For JSC, right now the cutoff is set to 256 bytes: https://github.com/WebKit/WebKit/blob/8bbba2aa777cf326e24a4e5c63b1f51bd52315ff/Source/JavaScriptCore/heap/Heap.h#L645

I realize another possible solution is that implementations with imprecise external memory tracking could treat change_in_bytes as a floor on the return value -- basically, pretending that at least the currently requested change has had an effect. On Node's side this would basically be a docs change instead of a test change. At a glance from the PR #14310 where this was originally added, it seems like the question of what to do with an engine that cannot track external memory at all was brought up but not resolved, and it doesn't look like the possibility of memory tracking existing but with a minimum was brought up. The documentation only really describes this function's effect in V8.

I'd be happy with either approach.

[legendecas]

IMO, the node-api adapter for WebKit should normalize small values if this is a WebKit constraint.

[mhdawson]

LGTM as the function is just providing additional info to the runtime which may or may not use. I'll submit a PR to add some additional info to the documentation to clarify that.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.21%. Comparing base (a790901) to head (3a3bc8f).
Report is 145 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #57351      +/-   ##
==========================================
- Coverage   90.21%   90.21%   -0.01%     
==========================================
  Files         630      630              
  Lines      185304   185304              
  Branches    36266    36267       +1     
==========================================
- Hits       167171   167164       -7     
+ Misses      11084    11083       -1     
- Partials     7049     7057       +8     

see 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[legendecas]

I think this should wait for #57463 (comment) to be resolved first. Add-ons may call the function with an arbitrary value of the size of allocated memory block, and there was no smallest limitation on the size.

want to wait until we finish discussion on doc update.

[190n]

Given the new docs from #57463:

• [out] result: The adjusted value. This value should reflect the
  total amount of external memory with the given change_in_bytes included.

I think this tests change is no longer desired, right?

[mhdawson]

@190n correct I think the implementation should be updated to reflect the doc update and then the test should pass.