[Development] Qt 5.9's new garbage collector documentation? + root_ptr

Edward Welbourne edward.welbourne at qt.io
Fri Jul 14 10:37:50 CEST 2017


André Pönitz (13 July 2017 19:20)
> There's no sensible reason to postpone "compilation" to run-time
> on a million feeble devices if there's any sensible way to do it
> ahead of time once on a beefy developer machine.

On the other hand, doing run-time optimisation (which is one of the
benefits a JIT is meant to give you) *does* have value; having the
engine capable of spotting which paths through the code actually do get
taken in real live use (rather than guessing during compilation; no
matter how good your heuristics, or how much the developer annotates the
code to help, real-world run-time will do things differently than you
thought) lets the run-time engine optimise those paths at the expense of
others.

Then of course there's the issue of trust: the user trusts the browser
to run code sand-boxed; neither the browser nor the user should trust a
binary downloaded from the internet; so the benefits you can gain by
pre-compiling incur the cost of running untrusted code.  Java deals with
that by running the compiled code in a VM that's sand-boxed; modern
ECMAScript (a.k.a. javascript) deals with running native code by only
doing so when the native code in question is what it generated, within
constraints that keep it inside the interpreter's sand-box.  (Which is
still somewhat scary, as JITs are software and software has bugs, that
attackers shall exploit; in this case, to trick a JIT into doing
something that breaks the sand-box.  So modern browsers are aggressive
about updating themselves.)

Oh, and many of our hand-held devices are far from feeble - but perhaps
my standards are a bit odd.  My first job involved sending code to run
on a Cray 1 at £1000 per hour; we're all now wasting cycles on more
powerful computers whose non-wasted cycles are mostly used to alleviate
boredom,

	Eddy.



More information about the Development mailing list