Add omrthread_get_thread_times()

[thallium]

This function returns the user and system cpu time of the calling thread.
This new function is needed so we can get both user time and
system time using only one system call.
Related: eclipse-openj9/openj9#20186

[tajila]

@babsingh Please review

[0xdaryl]

Minor nit: please fix the spelling of "thread" in your commit and PR titles. Thanks.

[thallium]

Fixed spelling

[babsingh]

The new function needs to be added similar to the existing functions in thrprof.c: example.

In the new function, the output of omrthread_get_cpu_time and omrthread_get_user_time is aggregated and returned. thrprof.c should have basic functionalities. The aggregation should be done in the upstream project. In other words, the new function shouldn't reside in OMR.

omrthread_get_user_time doesn't have support for Linux. Does anything prevent us to add Linux support in omrthread_get_user_time?

[tajila]

omrthread_get_user_time doesn't have support for Linux. Does anything prevent us to add Linux support in omrthread_get_user_time?

AFAIK, the only way to get user time reliably on linux is with getrusage(RUSAGE_THREAD, ... which can only be called on the current thread. This is why I proposed making a new API since the existing one takes an arbritrary thread as a param.

The goal is to do something like omrthread_get_process_times which returns omrthread_process_time_t

[babsingh]

The new function needs to be added similar to the existing functions in thrprof.c: example.

@thallium port and thread libraries are standalone. a thread library function shouldn't be added to the port library. see an existing function such as thrprof.c:omrthread_get_process_times and follow its implementation. the correct usage of the new function should require #include "omrthread.h" or #include "thread_api.h".

Also, include the justification in the commit on why the new function is needed.

[thallium]

Moved the function to thrprof.c

[babsingh]

jenkins build all

[babsingh]

jenkins build osx,amac,win

[keithc-ca]

When dwLowDateTime is negative, this yields the wrong result (it ignores dwHighDateTime).

See advice at https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime and example code in gtest.cc.

[thallium]

Can you explain how could dwLowDateTime be negative?

[keithc-ca]

Ok, dwLowDateTime uses the type DWORD which is equivalent to uint32_t (so it can't be negative). Either we need an extra cast to uint64_t before casting to int64_t (casts should not change both the width and signedness), or (preferred) we should follow the advice from Microsoft to use ULARGE_INTEGER and its QuadPart member like the example in gtest.cc I referenced.

[thallium]

I think Microsoft's advice is more about manipulating the time value so using ULARGE_INTEGER just to get the time value seems unnecessary to me. I'll open a PR to fix all the related casting.

[keithc-ca]

I expect doing as Microsoft advises will result in the same (or even better) code. Let's get this right.

[thallium]

Opened a PR: #7507