Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly

Jon Masamitsu jon.masamitsu at oracle.com
Tue Dec 1 18:11:15 UTC 2015


David,

Thanks again for looking at this.  Given the points that
Kim made, are you OK with this implementation?

The initialization is fragile and I hoped to fix it with the
least risk of collateral damage.  But I can look at it again
if you can suggest what to look for.  I don't claim to know why
things are the way they are.

And I'm going to add the needed empty definitions for
aarch64, ppc, and zero (Kim encouraged me to do that).
I intended to leave the linux/sparc alone for now.  I
don't think I have a build to test changes yet.

Jon

On 11/30/2015 10:14 PM, David Holmes wrote:
> On 1/12/2015 1:04 PM, Kim Barrett wrote:
>> On Nov 25, 2015, at 9:11 PM, David Holmes <david.holmes at oracle.com> 
>> wrote:
>>>
>>> We already have VM_Version::early_initialize() that can/should be 
>>> used for this if possible.
>>
>> VM_Version::early_initialize doesn’t work for this, because
>> determine_features (sparc) examines some command-line arguments, and
>> those aren't parsed until a later stage of Threads::create_vm.
>>
>> Specifically, determine_features (sparc) is presently looking at two
>> CLAs: UseV8InstrsOnly (develop) and UseNiagaraInstrs (product). I
>> suspect UseV8InstrsOnly has served its purpose and could be purged.
>> But calling determine_features before argument parsing would
>> unintentionally ignore UseNiagaraInstrs.
>>
>> Calling determine_features from os::init_before_ergo doesn't have 
>> this problem.
>>
>> [I missed this in my review of Jon’s original change to use 
>> early_initialize.]
>
> Thanks Kim. Still makes me wonder if it isn't something else that is 
> in the wrong place - the initialization dance is very tricky and I 
> hate to see yet-another-vm-version-init function added. Makes me 
> wonder whether determine_features should only look at what the 
> hardware provides, and then after argument processing is complete (or 
> appropriate portion thereof) we update the features that should 
> actually be used? - but that ship sailed long ago.
>
> David
>
>>



More information about the hotspot-dev mailing list