[External] : Re: Why does OSThread exist?

[coleen.phillimore at oracle.com]

On 12/7/21 9:42 AM, Thomas Stüfe wrote:
> 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?
Mostly code complexity and modularity.  Which is why I factored out the 
stack overflow code. If we can save some alignment gaps, that'd be good too.
>
> 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.

Unnecessary indirection is bad but indirection for locality is okay 
(imo).  But I agree this indirection for osthread might not make sense.

>
> 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.

I agree and I agree that osthread structure might be best factored 
directly in Thread.

My biggest thing I don't like is that in gdb print *thread is gives me a 
whole page of things that I don't care about to parse with my eyes, even 
with statics turned off.

What you're suggesting makes sense and I'll be glad to see it.

Coleen
>
> 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
>     >>>
>