RUMM-1276 VitalCPUReader is implemented

[buranmert]

What and why?

VitalCPUReader is implemented in order to measure CPU utilization of the app.

How?

host_statistics(...) method with HOST_CPU_LOAD_INFO parameter returns CPU utilization data from the kernel.
This low-level API requires working with pointers and type conversions; however

1. there is no higher level API to get such information
2. as this is the kernel, hopefully it's likely that they don't change often.

TODO

• testWhenCPUUnderHeavyLoad test case fails quite often, this must be fixed first kernel fails to report too small intervals, for loop counts increased.

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference

[mariusc83]

Why do you want to take system ticks into account ?

[buranmert]

at first i thought systemTicks might be meaningful in case of background network tasks where URLSession spawns another process to load the URL.
but then we decided to ignore cpu ticks at background state as they are unreliable, so yes i should remove systemTicks 👍

it's always 0 in an iOS device and under normal conditions (foreground state) anyway

[buranmert]

https://github.com/opensource-apple/xnu/blob/master/osfmk/kern/timer.h#L65
this should be the explanation why macOS reports both user and sys ticks while iOS reports user ticks only

https://github.com/opensource-apple/xnu/blob/master/osfmk/kern/host.c#L455
and this is probably where iOS returns false and puts all ticks into CPU_STATE_USER in the else clause

[ncreated]

Looks good 👍, but we need to reset unwanted changes to pbxproj.

[ncreated]

naming convention:

Suggested change

	func test_whenCPUUnderHeavyLoad_itMeasuresHigherCPUTicks() throws {
	func testWhenCPUUnderHeavyLoadItMeasuresHigherCPUTicks() throws {

[ncreated]

typo & naming convention:

Suggested change

	func test_whenInactiveAppState_itIggnoresCPUTicks() throws {
	func testWhenInactiveAppStateItIgnoresCPUTicks() throws {

[ncreated]

When I looked further, I can see that this will lead to threading issue. The readVitalData() will be accessed from background thread (by RUMScope), but the appWillResignActive() will be called on the main thread. Both access the utilizedTicksWhenResigningActive state by either reading or writing.

We can solve it later, when actually plugging VitalReaders to RUM (this will pop up in threading tests), but it's worth leaving this note.

[buranmert]

yes, that's a good point and i'm still not sure where the VitalReaders will live.
if they live in RUMMonitor we can read data in main thread within rum.start/stopView(...) methods (even before process(command:)) and that probably gives the most accurate measurement.
if they live in the scopes then we will need to add extra code as you said.

i'm leaving a comment 👍

[ncreated]

This test seems stable when running on a Mac, but when running on an iPhone, I receive ~13% failures. And it's coming from a reason that the highLoadAverage is sometimes 0. While we can call the last 3 failures a "flakiness" factor, the first 10 do rather look like some measurement issue, WDYT?

[buranmert]

now i'm running heavyLoad() for 1.0 second. that should improve test results.

although usually host_statistics updates its values after 0.01 second (which makes sense when we look at its source code), it sometimes keeps reporting the same values for 1.0 second (which doesn't make sense to me).
never 2.0 seconds or 0.5 second. i still can't figure out why.

i just noticed that when i do Thread.sleep(...), host_statistics returns updated values after 0.01 second most of the time.
without Thread.sleep(...) it usually doesn't update for 1.0 second.