Request for reviews (XXL): 6961690: load oops from constant table on SPARC
paul.hohensee at oracle.com
Thu Nov 18 14:29:50 PST 2010
It should be a check on a VM_Version method such as is_niagara. I expect
this to be a performance loss on non-T-series sparc.
On 11/18/10 2:30 PM, Vladimir Kozlov wrote:
> I like this code better but I still think that we should have a flag
> which controls how we load constant oops and longs.
> We may do it by just adding predicate(flag) into .ad file. Could you,
> please, check? And yes, we may need to keep some code you removed.
> Instead of using new flag ConstantTableAbsoluteAddressing (we have more
> flags than we need already) you should use Matcher's variable like next:
> const bool Matcher::clone_shift_expressions = true;
> I don't understand how MachConstantBaseNode::size() is not called
> on sparc where there is code generated for it? You need the size.
> It seems, you have to calculate it manually.
> I think you don't need to add_req() in constructor and then use
> set_req(root) since new MachConstantBase node is only created in
> Compile::mach_constant_base_node() so you can add_req(root) there
> Christian Thalinger wrote:
>> On Nov 17, 2010, at 10:35 AM, Christian Thalinger wrote:
>>> My fault. I was thinking that we're using RDPC when the node is not
>>> pinned, but that's not the case. Of course it works when not using
>> This became a bigger change that I thought it will be. I moved
>> almost all logic into Compile, the constant table emission and the
>> offset/size calculation are now two different steps which are called
>> explicitly in Compile::Fill_buffer, and the constant table base
>> materialization is not pinned.
>> -- Christian
More information about the hotspot-compiler-dev