Why does OSThread exist?

[Thomas Stüfe]

Hi Coleen,

I agree that Thread is a monster. Cleanup would be nice. But what is your
concern, footprint of this structure, or code complexity?

Footprint-wise, OSThread contains information that is vital for any thread
(thread state, thread id etc). You always need those, so you always need to
store them. By keeping them in a physically separated structure we don't
gain anything. We still pay for the storage. We pay more, actually, since
there is the per-structure overhead incurred by the libc. Also, runtime
overhead for mallocs. And runtime overhead for the unnecessary indirection
when accessing the thread id or thread state, both of which are at least
warm.

If it is about code complexity, and separation of concerns, I think it
makes sense to factor some things out of Thread. E.g. by composition or
inheritance. But IMHO moving things physically out of Thread only makes
sense if the parts you move out are optional and not always needed.

Also, this may be just me but it seems weird to have Thread/JavaThread
chock-full of all kinds of members but have the thread id of all things
factored out into a companion structure.

Cheers, Thomas



On Tue, Dec 7, 2021 at 3:13 PM <coleen.phillimore at oracle.com> wrote:

>
> I've been unhappy with thread.hpp being catch-all for everything with
> nothing factored out.  Thread can still point to things but I'd hate to
> see more stuff go into thread.hpp/cpp.  Please don't go in this direction.
>
> See also: https://bugs.openjdk.java.net/browse/JDK-8264145
>
> thanks,
> Coleen
>
> On 12/7/21 8:56 AM, Thomas Stüfe wrote:
> > Hi David,
> >
> > On Tue, Dec 7, 2021 at 10:25 AM David Holmes <david.holmes at oracle.com>
> > wrote:
> >
> >> Hi Thomas,
> >>
> >> On 7/12/2021 4:30 pm, Thomas Stüfe wrote:
> >>> Hi,
> >>>
> >>> does anybody know what the point is of a separate OSThread companion
> >> class
> >>> to Thread? I understand that there is OS-specific information one wants
> >> to
> >>> factor out on a per-platform base, but why two physically separate
> >>> structures? AFAICS they never exist separately (an OSThread makes no
> >> sense
> >>> without a Thread, and vice versa). We pay unnecessarily for two
> >>> allocations, C-heap fragmentation, and for one additional dereferencing
> >> hop
> >>> when accessing OSThread.
> >> Can say for sure as it is historical - it's just the way the OS specific
> >> part was factored out.
> >>
> >> We had a project to try and get rid of it a few years ago but it wasn't
> >> a clean/simple as thought at the time and the project was dropped. But
> >> Solaris complicated things and now that's gone so ...
> >>
> >>
> > Thanks for the explanation. This tickles my cleanup sense and maybe I try
> > my hands on it, now Solaris is gone.
> >
> > Cheers, Thomas
> >
> >
> >
> >> Cheers,
> >> David
> >>
> >>> Thanks, Thomas
> >>>
>
>