We can lose profiling timer events for a few reasons, for example
disabled interrupts or system slowness. This accounts for lost
time between CPU samples by adding a field lost_samples to each
profiling event which tracks how many samples were lost immediately
preceding the event.
Now that the profiling timer is independent from the scheduler the
user will get quite a few CPU samples from "within" the scheduler.
These events are less useful when just profiling a user-mode process
rather than the whole system. This patch adds an option to Profiler to
hide these events.
Previously Profiler would use the stack depth to draw the timeline
graphs. This is not an accurate representation of whether a thread
is "busy" or not. Instead this updates the timelines to use the
sample count.
This check only existed to prevent crashing the target process back
when programs were listening for incoming Inspector connections.
Now that we talk to InspectorServer instead, and it already has a
communication channel with the target, this is no longer an issue.
Since applications using Core::EventLoop no longer need to create a
socket in /tmp/rpc/, and also don't need to listen for incoming
connections on this socket, we can remove a whole bunch of pledges!
Core::EventLoop now makes an outbound connection to InspectorServer
instead of listening for incoming connections on a /tmp/rpc/PID socket.
This has many benefits, for example:
- We no longer keep an open listening socket in most applications
- We stop leaking socket files in /tmp/rpc
- We can tighten the pledges in many programs (patch coming)
This service daemon will act as an intermediary between the Inspector
program and the inspectable programs it wants to inspect.
Programs can make themselves available for inspection by connecting
to /tmp/portal/inspectables using the Core::EventLoop RPC protocol.
It's frustrating when the system is under heavy load and you want to
investigate using SystemMonitor, but SystemMonitor chokes on the lag.
Let's at give it a fighting chance by maxing out the main thread prio.
Matrix4x4 was defined as a derived class of Matrix<N,T> before.
Furthermore, some code was duplicated and it was overall just messy.
This commit turns Matrix4x4 into a simple alias for Matrix<4,T>.
Matrix elements were interpreted in different ways.
This makes it definitely row-major, allowing initialization via
initializer list in a standard scientific order. Also matrix
multiplication now happens in the correct order and accessing
elements happens as m_elements[row][column].
Previously, this was parsing only one kind because I mistakenly assumed
that they all had the same shape, now it can parse two kinds, and will
return NotImplemented for the rest.
This adds very basic support for module instantiation/allocation, as
well as a stub for an interpreter (and executions APIs).
The 'wasm' utility is further expanded to instantiate, and attempt
executing the first non-imported function in the module.
Note that as the execution is a stub, the expected result is a zero.
Regardless, this will allow future commits to implement the JS
WebAssembly API. :^)
With this, the parser should technically be able to parse all wasm
modules. Any parse failure on correct modules should henceforth be
labelled a bug :^)
We never really needed the 512 words in the first place, and this does
reduce the stack allocations in montgomery modular power from 32Kb to
a more manageable 2Kb :^)
Note that the 32 words size doesn't provide any performance benefits or
drawbacks compared to other values. All values seem to have equivalent
performances (the tested values were 1, 2, 4, ..., 512). But since the
previous value of 512 was definitely too big, let's reduce it for now!
This algorithm allows for much faster computations of modular powers
(around a 5x-10x speedup of the Crypto test). However, it is only valid
for odd modulo values, and therefore the old algorithm must be kept for
computations involving even modulo values.
Since the operations are already complicated and will become even more
so soon, let's split them into their own files. We can also integrate
the NumberTheory operations that would better fit there into this class
as well.
This commit doesn't change behaviors, but moves the allocation of some
variables into caller classes.
This is working fine for TLS because we have a big enough inline
capacity, but in theory we could have crashed at any time even with
our 512 words of inline capacity.
The Acid1 test has a bit of an unusual background - the html and body
tags have different background colors. Our painting order of the DOM was
such that the body background was painted first, then all other elements
were painted in-phase according to Appendix E of CSS 2.1. So the html
element's background color was painted over the body background.
This removes the special handling of the body background from
InitialContainingBlockBox and now all boxes are painted in-phase. Doing
this also exposed that we weren't handling Section 2.11.2 of the spec;
when the html background is unset, the body's background should be
propagated to the html element.
The ListItemMarker gets its index 1-based while the
String::bijective_base_from expects its index to be 0-based. This patch
adjusts the index passed around accordingly.
This untangles several concepts in the rasterizer and makes it possible
to toggle different stages on a per-block level rather than having to
check whether the feature is enabled for every pixel.
This makes the software rasterizer use integers for triangle coverage
calculations. The previously used floating point algorithm was not
precise enough in certain situations and showed gaps between triangles.
This is not yet subpixel accurate.
