RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file.
Max Ockner
max.ockner at oracle.com
Thu Mar 5 05:16:54 UTC 2015
Serguei-
I originally tested with JPRT, vm.quick.testlist, and
nsk.jvmti.testlist. After making formatting changes, I retested with
nsk.jvmti.testlist. Still, just to be safe, I also retested with
vm.quick.testlist today.
John-
The _new operator used registers that weren't available on 64 bits, so
the 32 bit version was kept.
Thanks,
Max
On 3/3/2015 7:00 PM, serguei.spitsyn at oracle.com wrote:
> Hi Max,
>
> A minor comment.
> The testlist (nsk.jvmti.testlist) looks strange.
> I'd expect at least some runtime tests to be run.
>
> Thanks,
> Serguei
>
>
> On 3/3/15 1:39 PM, Max Ockner wrote:
>> Hello all,
>> I have made all of the changes recommended by Chris and John. I
>> realize there are plenty of further cleanups and optimizations that I
>> could make, but I think this is nearing a good stopping point for
>> now. We can always clean it up more later. What do you think?
>>
>> new webrev: cr.openjdk.java.net/~coleenp/8013393
>> tested with nsk.jvmti.testlist
>>
>> On 3/2/2015 4:45 PM, John Rose wrote:
>>> On Mar 2, 2015, at 11:46 AM, Christian Thalinger
>>> <christian.thalinger at oracle.com> wrote:
>>>> That’s quite a large change (I wish we had Crucible or something to
>>>> leave inline comments).
>>>>
>>>> First, you have to keep the oldest copyright year (but maybe that’s
>>>> just the diff).
>>>>
>>>> + #ifdef _LP64
>>>> + void TemplateTable::lconst(int value) {
>>>>
>>>> I’d prefer to have #ifdef’s inside methods and not around them.
>>>> There are a bunch; please change all of them.
>> I have moved the #ifdef's to the inside of the function declarations.
>> Some of the #ifdefs could be moved far enough in that it made sense
>> to replace them with the LP64_ONLY() or NOT_LP64() tools. The
>> remaining #ifdef's are there because some large sections of code
>> could not be merged, and needed to be kept together.
>>
>>> I agree Christian's comments, and especially with this request.
>>>
>>> A few more points on small matters:
>>>
>>> In our source base, C++ comments usually begin with two slashes and
>>> a space (less than 10% exceptions).
>>> +//Global Register Names
>>> +//Address Computation: local variables
>>> (etc.)
>>
>> Fixed.
>>
>>> Let's use the term "amd64" only where required; x86_64 is the
>>> standard now.
>>> // No amd64 specific initialization
>>
>> Fixed.
>>
>>> More on #ifdefs: I think there are too many; Chris has pointed out
>>> the main problem.
>>>
>>> It's a judgement call, but here's another example:
>>>
>>> +#ifdef _LP64
>>> + Register rtmp = r8;
>>> + Register rthread = r15_thread;
>>> +#else
>>> + Register rtmp = rsi;
>>> + Register rthread = rcx;
>>> + __ get_thread(rcx);
>>> + __ save_bcp();
>>> +#endif // _LP64
>>>
>>> could just as well be:
>>>
>>> + Register rtmp = LP64_ONLY(r8) NOT_LP64(rsi);
>>> + Register rthread = LP64_ONLY(r15_thread) NOT_LP64(rcx);
>>> + LP64_ONLY(__ get_thread(rcx));
>>> + LP64_ONLY(__ save_bcp());
>>>
>>> Advantages: Fewer lines, less duplication, less chance of merge
>>> problems.
>>> Possible objection: Ugly; but only in a different way from the
>>> other ugly.
>>
>> Fixed, but there are some #ifdef's left over. There are some pretty
>> large code blocks that are conditionally defined. I don't think it
>> makes sense to enclose every conditionally defined line of code in an
>> LP64_ONLY or NOT_LP64. At best you save 3 lines of code, but I feel
>> that a those 3 lines would be less distracting than having 25
>> LP64_ONLY's in a row.
>>>
>>> However, I admit that is a marginal example.
>>>
>>> — John
>>
>> Thanks,
>> Max Ockner
>>
>
More information about the hotspot-dev
mailing list