Avi Halachmi (:avih) b5eccea611 gc: use proportional instead of fixed threshold
The problem with a fixed count value is that it result in varying
degrees of performance and memory impact proportions depending on
the usage pattern of each script.

E.g. if a script keeps using the same 1M objects, then a threshold of
10K objects will result in GC cycles which free only 1% of objects,
which is hugely wasteful in terms of performance. On the other hand,
if a script only uses 100 objects then a threshold of 10K means it
uses 100 times more memory than it actually needs before GC triggers.

Now the threshold is a target memory usage factor (of the minimum
needed memory) which GC tries to aim at. This makes the GC impact
have constant proportions.

The default aims at a memory usage factor of 5, i.e. 80% garbage
and 20% remaining on each GC cycle.

The factor is only a target/goal because the actual overhead is not
known until GC completes. However, most scripts exhibit consistent
enough behavior such that the real overhead is within 10% or less of
the goal even when the usage pattern changes over time.

Within the v8 bench test suite, the actual GC threshold count varies
between ~50K to ~500K, where only one test (raytrace.js) stabilizes on
less than 10K (the previous fixed default) - at about 9K and its score
decreases by ~5%.

The splay.js score increases about x12 fold (or x50 fold from the
previous commit which counts properties), other tests quite a bit
less or none at all, and the overall score increases by nearly 40%.

Also, change the count type from int to unsigned int to get twice the
range. Preferably we should make it even bigger, maybe uint64_t.

For instance the splay.js v8 bench test surpasses million non-garbage
allocations within few seconds (that's why its score increased so much
with a proportional overhead), and the default GC threshold is 5 times
that number.
2020-07-23 12:40:09 +02:00
2020-05-27 12:32:32 +02:00
2020-01-02 14:37:05 +01:00
2020-05-27 12:32:32 +02:00
2020-05-27 12:32:32 +02:00
2020-05-27 12:32:32 +02:00
2020-07-06 11:04:32 +02:00
2020-05-27 12:32:32 +02:00
2018-11-26 10:40:22 +01:00

MuJS: an embeddable Javascript interpreter in C.

ABOUT

MuJS is a lightweight Javascript interpreter designed for embedding in
other software to extend them with scripting capabilities.

LICENSE

MuJS is Copyright 2013-2017 Artifex Software, Inc.

Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.

The software is provided "as is" and the author disclaims all warranties with
regard to this software including all implied warranties of merchantability
and fitness. In no event shall the author be liable for any special, direct,
indirect, or consequential damages or any damages whatsoever resulting from
loss of use, data or profits, whether in an action of contract, negligence
or other tortious action, arising out of or in connection with the use or
performance of this software.

COMPILING

If you are building from source you can either use the provided Unix Makefile:

	make release

Or compile the source with your preferred compiler:

	cc -O2 -c one.c -o libmujs.o

INSTALLING

To install the MuJS command line interpreter, static library and header file:

	make prefix=/usr/local install

DOWNLOAD

The latest development source is available directly from the git repository:

	git clone http://git.ghostscript.com/mujs.git

REPORTING BUGS AND PROBLEMS

Report bugs on the ghostscript bugzilla, with MuJS as the selected component.

	http://bugs.ghostscript.com/

The MuJS developers hang out on IRC in the #mupdf channel on irc.freenode.net.
Description
An embeddable Javascript interpreter in C.
Readme 1.7 MiB