- With modules JavaScript code can be split up into multiple files. We
already implemented such a mechanism (`Engine.LoadLibrary`) in
multiple parts of the engine. The advantage of using modules is
that it's standart (JS-devs are familiar with it) and it doesn't
has to be implemented multiple times.
Note that `Engine.LoadLibrary` loads all files in a directory
while the new `import` only loads one file.
- With modules seemingly global variables are local to that
script/module. We already implemented such a mechanism
(`ScriptInterface::LoadScript`).
As noted on #7979, we run into OOMs since commit af32d386b9. The reason is that the default incremental GC budget is unlimited, which actually doesn't perform incremental GCs. Our settings can lead to situation where the incremental GCs don't actually sweep, thus not freeing memory.
SM has a mechanism to avoid OOM anyways with LAST_DITCH GCs, but by default these can only occur ever 30 seconds. Turn this off.
Reported by: langbart
Shrinking GCs dump the JITted code, which leads to redundant recompilations, lowers performance, and makes profiling JS more difficult.
They may still happen if the runtime is at risk of OOM.
SpiderMonkey 98 introduced a size heuristic for the nursery GC region
(https://phabricator.services.mozilla.com/D136637). As this heuristic
uses a wall-clock time duration, it results in a severe performance
regression on slower systems for our use case.
This commit adds a workaround to turn off that heuristic, by telling
SpiderMonkey that a "page load" (something which doesn't have a meaning
in the context of pyrogenesis) is in progress, as that heuristic is
disabled for page loads.
Co-Authored by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Fixes#7714
The context option enabling strict mode was removed in sm-117 [1]
requiring to use the compiler option for the same purpose instead.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1621603
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
- Shallow-freezing of objects is never used in our codebase, so remove
that code path.
- Deep-freeze is bugged in recent versions of SpiderMonkey (see bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1930258). Until a fix
and/or a better API is provided, reimplement this feature by
recusively freezing object properties.
- Add tests for the deepfreeze function.
When calling `Engine.PushGuiPage` a promise is returned. The promise is
settled when the "child" page is closed. That allows to `await` it
inside `async` functions.
Previously the callback was run right inside the call to
`Engine.PopGuiPage`. Now the continuation of the promise is called at
the end of the "tick".
This won't help performance. It will more likely make things worse.
Since gui pages aren't opened or closed that frequently, it doesn't
matter that much.
Refs: 86c151ebaa
For the engine side:
The promise is stored in the `CGUIManager::SGUIPage` (like previously
the callback). When the promise is fulfilled it enqueues a callback in
the `JobQueue` of the `JSContext`.
Original patch by: @wraitii
Comments by: @wraitii, @Stan, @Polakrity, @lyv, @elexis, @vladislavbelov
Differential Revision: https://code.wildfiregames.com/D3807
This was SVN commit r28145.
This way it's clear what's the input and what's the output of the
computation.
All map generation scripts should reman working. They are adopted in a
future commit.
`Engine.SetProgress` and `Engine.ExportMap` can be removed in a future
commit.
Comments by: @marder, @sera, @Stan
Differential Revision: https://code.wildfiregames.com/D5220
This was SVN commit r28093.
The return-slot provided by the `Future` is used for synchronisation.
Refs: #5874
Comments By: @Stan, @vladislavbelov, @wraitii
Differential Revision: https://code.wildfiregames.com/D5001
This was SVN commit r27944.
Avoid cases of filenames
Update years in terms and other legal(ish) documents
Don't update years in license headers, since change is not meaningful
Will add linter rule in seperate commit
Happy recompiling everyone!
Original Patch By: Nescio
Comment By: Gallaecio
Differential Revision: D2620
This was SVN commit r27786.
ScriptFunction::Call_ checks HasProperty, but then JS_CallFunctionName
calls GetProperty. This is redundant and can be simplified.
Reviewed By: phosit
Differential Revision: https://code.wildfiregames.com/D5000
This was SVN commit r27726.
SPECTRE attacks mitigations were added to SpiderMonkey's JIT output in
version 57. Turning these off is a very large speedup, around 10-20%
wall time (on my computer) depending on the map and the situation.
For the most part, from profiling on my machine, this is from memory
fences after JIT -> C++ calls. 0 A.D. does a lot of these.
The SPECTRE class of attack is a timing attack based on speculative
execution to leak sensitive information, and it seems extraordinarily
unlikely that something like this could be successfully mounted using 0
A.D.
Differential Revision: https://code.wildfiregames.com/D5014
This was SVN commit r27699.
This is unused and makes the function twice as slow as it needs to be.
Differential Revision: https://code.wildfiregames.com/D5015
This was SVN commit r27697.
This is a paradigm change for AI computation.
Historically, the AI was intended to be run in a separate thread from
the simulation. The idea was that slow AI wouldn't stop the renderer
from being smooth.
In that original design, the AI received a copy of the game world and
used that to run its logic. This meant the simulation could safely do
whatever it wanted in the meantime. This copy was done via AIProxy &
AIInterface.
This design ended up having significant flaws:
- The copying impacts the simulation negatively, particularly because
AIProxy subscribes to a lot of messages (sometimes sent exclusively to
it). This time cannot be threaded, and impacts MP games without AIs.
- Copying the data is increasingly difficult. Modifiers are a headache,
LOS is not implemented. Lots of logic is duplicated.
The intended benefits of the design also failed to realise somewhat:
- The AI was never threaded, and in fact, it is probably better to try
and thread Sim + AI from the renderer than just the AI, at which point
threading the AI specifically brings little benefit.
The new design is much simpler and straighforward, but this has some
side-effects:
- The AI can now change the simulation. This can be used for cheating,
or possibly for a tutorial AI.
- The AI runs in the same GC zone as the simulation, which may lead to
more frequent Sim GCs (but overall we might expect a reduction in
temporary objects).
- The AI state was essentially cached, so replacing some functions with
Engine.QueryInterface might be slower. The tradeoff should be balanced
by lower AIProxy computation times.
Future work:
- Threading some specific AI tasks could still be worthwhile, but should
be done in specific worker threads, allowed to run over several turns if
needed.
Technical note: the AI 'global' is in its own Realm, which means name
collisions with the same are not possible.
Other notes:
- The RL Interface uses the AI Interface and thus will gradually lose
some data there. Given that the RL Interface can now request data
however, this should be dine.
Refs #5962, #2370
Differential Revision: https://code.wildfiregames.com/D3769
This was SVN commit r26274.
If a *nix user wishes to build `pyrogenesis` with support for Valgrind
(such as
it is), then can do so by passing `--with-valgrind` to
`update-workspaces.sh`.
(They will need Valgrind installed and locateable via `pkg-config`.)
Reviewed By: sera, Stan
Fixes: #2904
Differential Revision: https://code.wildfiregames.com/D3646
This was SVN commit r25933.
As no default values got set, some game settings became NaN, which
triggered exceptions.
This sets sane default.
This also includes better debugging logic in case of exception, so it's
easier to know what happens.
Fixes#6200
Reported by: langbart
Differential Revision: https://code.wildfiregames.com/D4113
This was SVN commit r25736.
This removes usage of CmptPrivate outside of ScriptInterface.
ScriptRequest can now be used to safely recover the scriptInterface from
a JSContext instead of going through ScriptInterface, which allows more
code cleanup.
Follows 34b1920e7b
Differential Revision: https://code.wildfiregames.com/D3963
This was SVN commit r25442.
Follows 34b1920e7b.
JSON functions and ToString are movec to their own headers.
Also clean out a few PersistentRooted usage to use the 2-phase init to
clean up scriptInterface usage.
With these functions split off, we can finally clean out headers and
remove ScriptInterface.h from most of them, in favour of smaller and
more precise headers.
Take the opportunity to clarify some comments regarding Mutability.
Differential Revision: https://code.wildfiregames.com/D3961
This was SVN commit r25434.
The one in ScriptInterface_Impl is actually used.
Introduced in e9e05f4efc and from what I can tell never actually used.
Differential Revision: https://code.wildfiregames.com/D3960
This was SVN commit r25433.
Follows 34b1920e7b.
This splits off the object-related functions, such as
[Set/Get/Has]Property, CreateObject, CreateArray, FreezeObject.
It also puts the definitions in the header itself, which might end up
with faster code here & there, though perhaps slower compilation time
(somewhat doubtful since we already included most things anyways).
Differential Revision: https://code.wildfiregames.com/D3956
This was SVN commit r25430.
All ToJSVal/FromJSVal definitions are put in a separate header.
Remove AssignOr[To/From]JSVal duplication.
The functions were already static so this is rather straightforward.
Follows 34b1920e7b and 2bae30c454
Differential Revision: https://code.wildfiregames.com/D3953
This was SVN commit r25428.
Follows 34b1920e7b.
This separates StructuredClone & DeepCopy logic into its own header,
reducing the size of the monolithic ScriptInterface header.
Differential Revision: https://code.wildfiregames.com/D3922
This was SVN commit r25419.
Completes work starting in D2313 / a33fd55e81:
- Make C++ mistakes where values can be changed without messages being
sent easier to notice / harder to do.
- Make the IGUISetting interface more flexible, allowing custom settings
implementing their own logic. This is used to clean up hotkey code
introduced in 33af6da5e1.
Side effects:
- FromJSVal_Vector clears the vector being passed in. I have some vague
memory of not doing that in D24 / 2bae30c454 as an optimisation, but it
seems more like a footgun to me.
- Most usage of SetSettingFromString is replaced by direct method calls,
as we can generally cast to the proper GUI object type. Where we can't,
it is kept as a poor's man virtual dispatch.
- It moves a few member variables elsewhere, e.g. TextOwner now gets its
own member variable settings.
Differential Revision: https://code.wildfiregames.com/D3892
This was SVN commit r25392.
We often only need to include ScriptRequest.h and not the full
ScriptInterface.h
Differential Revision: https://code.wildfiregames.com/D3920
This was SVN commit r25366.
This prints out a stack trace, which is quite helpful when debugging.
Also fixes an issue with stack trace not always being reported.
Differential Revision: https://code.wildfiregames.com/D3210
This was SVN commit r25365.
- 25332f9b86 added 'override' to a method in ShaderProgram.cpp. This
adds it to the rest.
- BinarySerializer.cpp had custom JS includes, because putting those in
ScriptExtraHeaders failed. The cause is that gloox leaves "#define
lookup" up. This has been reported upstream, and fixed here.
- VS17 complains about an uninitialised variable, though the usage is
safe.
Differential Revision: https://code.wildfiregames.com/D3916
This was SVN commit r25359.
