erts: Add start_time to process_info/2

[stolen]

This PR makes possible to get process start time.

Internal process struct already had approx_started field
containing system time at the moment the process was started.
Now it is possible to get this value via process_info/2.

This is useful for system analysis. Sometimes you want to know how long
given process is running, but currently you need logs or special code
(e.g. storing start time in process dictionary) to get that information.

[fenollp]

Would a resolution better than seconds be useful? Say microseconds?

[stolen]

@fenollp It would.
It also would be more consistent to have timestamp in native time units.
But that would require to change the way start time is stored and retrieved, causing small degradation in memory efficiency and crashdump generation speed.

[rickard-green]

We don't want to introduce a new value that later needs to be changed. The obvious request for change is the one above, i.e., better resolution. Another is time in Erlang monotonic time instead of OS system time.

Current implementation store this time in each process structure using a 32-bit integer on 32-bit architectures and a 64-bit integer on 64-bit architectures. In order to be able to provide this information in native time unit, it needs to be stored in a 64-bit integer also on 32-bit architectures which I don't see as much of an issue. The information returned from process info should also in my opinion be in Erlang monotonic time and not in OS system time since you then actually will be able to know for how long time the process has lived.

Another possible change would be to remove this functionality all together (i.e. no information at all about this in the crash dump). This would save a word in all process structures which might not seem as much, but in the end can be quite a lot. How useful is this information really?

[stolen]

@rickard-green I agree on storing and returning Erlang monotonic time.

How useful is this information really?

Well, it seems useful to me for inspecting a system which has Pid serial wrapped many times.
Someone might use it for ensuring stored pid has not been re-used by a new process.

Maybe we should ask the community to see if people really need this?

[fenollp]

The people over at @erlanglab might have uses for this.

[stolen]

@rickard-green according to activity in this PR and erlang-questions ML, it seems like some people need this (especially ones working on tracing tools), no one worries about memory and crashdump performance cost, and most just don't care.

Also I've changed stored and returned time to Erlang monotonic time (native units).

[rickard-green]

When we discussed this internally here at OTP @garazdawi came up with an alternative that I find nice:

Introducing a startup parameter (and system_flag) that enables this feature. Without it the, feature doesn't exist. When disabled no extra memory is needed (i.e. we can remove the word used today), and when enabled the information is stored in PSD (process specific data). PSD only consume memory when used.

Besides this feature other statistics features could be enabled the same way. An example could be process specific microstate accounting.

[rickard-green]

We've decided to save this memory in the process structure. If this feature should exist, it should be controlled via an option so that you explicitly need to enable it. I'm therefore rejecting this PR.

[stolen]

OK.
So, could you suggest startup parameter and system_flag names?
Re-implementing this feature using PSD seems quite straightforward, but ability to enable it explicitly requires some naming.

[garazdawi]

I suggest "erl +Pstats true|false" and "erlang:system_flag(process_stats, true | false)".

[rickard-green]

A system_info(process_stats) so you can determine if it has been enabled or not is nice as well.

[okeuday]

This pull request approach is now being discussed at https://bugs.erlang.org/browse/ERL-623 if anyone wants to provide more discussion there.