review (S) for 6989736: fix mapfile warnings on solaris

[Tom Rodriguez]

Sounds good to me.  Thanks for the reviews.

tom

On Oct 5, 2010, at 5:19 PM, Vladimir Kozlov wrote:

> Tom Rodriguez wrote:
>> On Oct 5, 2010, at 4:15 PM, Vladimir Kozlov wrote:
>>> Tom,
>>> 
>>> It seems, nobody want to spend time to regenerate reorder files
>>> for several years already. What we only do is removing lines
>>> from these files which produce warnings. May be we should add
>>> your script into sources and use it more frequently:
>> Yes they are dying a death of a thousand cuts.  If I remember correct, removing their use seemed to hurt startup but regenerating them didn't seem to help.  I'd rather not put the script in the repo though.
> 
> It was true several years ago when I tried to regenerate
> them using collector/analyzer tool which can produce map files.
> I got regression so I dropped the project.
> 
> I agree with John Coomes that we should see how they
> affect performance in current state and remove them.
> 
> But for now I want this cleanup since we don't know when
> 6989819 will be processed.
> Tom, you can go with current change (without script in sources).
> 
> Thanks,
> Vladimir
> 
>> tom
>>> make/solaris/clear_mapfile_warnings.sh
>>> 
>>> Otherwise looks good.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> Tom Rodriguez wrote:
>>>> http://cr.openjdk.java.net/~never/6989736
>>>> 6989736: fix mapfile warnings on solaris
>>>> Reviewed-by:
>>>> The map files are getting out of date resulting in a bunch of warnings
>>>> for product builds so it's time to clean them again.  The 64 bit
>>>> tiered reorder files have only recently started being used and those
>>>> have a lot of entries out of date.  I also fixed a minor build issue
>>>> where the first build of the adlc didn't run the fix_lines portion of
>>>> the adlc_updater which caused the next incremental build to regenerate
>>>> some files because the #line directives had changed.  Tested by
>>>> building each target.  I attached the automated script I used for this
>>>> to the bug report.