RFR [M] : 8087333, Optionally Pre-Generate the HotSpot Template Interpreter

[Bertrand Delsart]

On 23/06/2015 07:52, David Holmes wrote:
> On 20/06/2015 3:55 AM, Bertrand Delsart wrote:
>> Thanks David,
>>
>> Further trimming, keeping only the open questions and action items.
>>
>> In addition, I had to revert back some of what I have undone in
>> webrev.01.
>>
>> Removing the %.S rule did not work as expected on all targets. gcc
>> handles differently 's' and 'S' files, doing the preprocessing only for
>> the 'S' extension. Hence I added back the %.S rules but without all the
>> C/C++ related FLAGS. The %.S rule is the same as the %.s rules (except
>> for the printed message) but gcc does something different thanks to the
>> effective file extension.

While investigating why I had added the .S files for this CR, I noticed 
that aarch64 open port has some .S files checked-in but no rules to 
compile them. To avoid triggering the compilation and linking of these 
(obsolete?) files in the open aarch64 port, I had to modify the change 
in vm.make.

The list is now controlled by a Src_Files_BASE variable. *.S files are 
now added to the BASE only in our closed extensions.

On the other hand, I've kept the new %.S rule in the open because, if 
other ports do need a rule for .S files, we should try to converge on a 
rule that works for all .S files (avoiding future conflicts if we start 
mixing .S files that depend on a given rule and other .S files that 
depend on another one).

Incremental diff:

+Src_Files_BASE += \*.c \*.cpp \*.s

# Locate all source files in the given directory, excluding files in 
Src_Files_EXCLUDE.
define findsrc
          $(notdir $(shell find $(1)/. ! -name . -prune \
-                -a \( -name \*.c -o -name \*.cpp -o -name \*.s -o -name 
\*.S \) \
+                -a \( -name DUMMY $(addprefix -o -name 
,$(Src_Files_BASE)) \) \
                  -a ! \( -name DUMMY $(addprefix -o -name 
,$(Src_Files_EXCLUDE)) \)))
endef

>> Note sure the closed platforms are worth fixing in this CR since I saw
>> errors in files that have not been touched for a long time. It probably
>> means nobody is doing non-PCH builds for these platforms.
>
> Nobody is but it has been a long standing item on my to-do list to fix it.

I've fixed them :-) Was waiting for comments on the other points before 
updating the webrev.

> A consolidated webrev.02 might be in order - I think Coleen has only
> looked at .00

Will send it in a separate e-mail with a summary of the cleanup from 00 
to 02.

Regards,

Bertrand.

-- 
Bertrand Delsart,                     Grenoble Engineering Center
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38330 Montbonnot Saint Martin,                             FRANCE
bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~