RFR (M) 8199282: Remove ValueObj class for allocation subclassing for gc code

[David Holmes]

<trimming>

On 13/03/2018 12:23 PM, Kim Barrett wrote:
>> On Mar 12, 2018, at 5:21 PM, coleen.phillimore at oracle.com wrote:
>> On 3/12/18 4:51 PM, Kim Barrett wrote:
>>>> On Mar 12, 2018, at 10:49 AM, coleen.phillimore at oracle.com wrote:
>>> src/hotspot/share/runtime/osThread.hpp
>>>
>>>   56 // I'd make OSThread a ValueObj embedded in Thread to avoid an indirection, but
>>>    57 // the assembler test in java.cpp expects that it can install the OSThread of
>>>    58 // the main thread into its own Thread at will.
>>>
>>> Removal of the comment doesn't seem right, unless we're really never
>>> going to change this.  Just deleting "a ValueObj" would be sufficient
>>> here.
>>>
>>> Any idea what assembler test is being referred to here?  I didn't look
>>> too hard, but I didn't find what prevents embedding OSThread into
>>> Thread.
>>
>> I think the entire comment is obsolete and is something that doesn't make sense to change.  No idea what the assembler test is.  Rather than trying to reword a now meaningless comment, I removed it.

That comment dates back to 1997 - by John Rose. I believe it refers to 
this in the ancient vm_main function:

  if (TestAssembler) {
     printf("Sparc assembler test");
     MacroAssembler::test();
     JVM_Exit(0);
  }

Definitely obsolete and should be removed.

> That just begs the question.  Why isn't OSThread directly embedded in
> Thread, rather than being a separate object?  Eliminating the
> indirection seems like it might be useful.  Is there a downside?

We had a project to get rid of OSThread completely a few years ago. 
Unfortunately it turned out to be somewhat larger to deal with than 
anticipated and the project was canned due to lack of resources. IIRC 
the main issues involved resolving OSThread states versus JavaThread 
states versus java.lang.Thread states.

Given ideally we'd get rid of OSThread do we want to expend effort 
seeing if we can embed it in Thread? I don't see any real gain here, but 
as with any change there is a risk of disturbing something non-obvious. 
If it ain't broke ...

David