Generated compiler command file overrides user specified compiler command file

[Aleksey Shipilev]

I think you accidentally attached the previous patch.

-Aleksey

On 28.05.2014, at 12:35, Nitsan Wakart <nitsanw at azulsystems.com> wrote:

> Revised patch attached!
> 
> On 27/05/14 21:17, Aleksey Shipilev wrote:
>> On 05/27/2014 11:07 PM, Nitsan Wakart wrote:
>>>>> 2. The merge expects 0 or one CompileCommandFile to be specified
>>>>> by the user. Only the first file is merged. Others are ignored.
>>>> Merging the first file is OK, since Hotspot will normally ignore
>>>> multiple -XX:CCF.
>>> You are right, but it will take the last, not the first. I think we
>>> should do what the JVM should have done here and not allow
>>> it(preferred) OR merge them all.
>> All right, since multiple CCFs are the corner case nobody will use,
>> let's shoot for code clarity, and merge them all.
> Merging all. Handling the .hotspot_compiler case as well.
>>>> * What's the reason hintsFile and hintsFile(String) are almost
>>>> identical? Can we merge them together? Also,
>>>> RunnerTest.tempFileWithLine is also similar. Should we introduce
>>>> the utility method? Get that into Utils.
>>> You are right on code smell. The difference here is that the hints
>>> file is cached when default but notionally needs rebuilding when
>>> merging is required(could introduce a map if cache is required).
>>> I'll come up with a better solution, but clarification on the need
>>> for caching is appreciated.
>> The caching there is the performance optimization, and it was proven
>> useful (think about the case when there are thousands of hints --
>> realistic for large benchmark suites). At the first slab, it might be
>> enough to just extract the file building part from both your methods
>> into a util method, and leave caching alone.
> Caching is maintained for the JMH hints files. Merging is a separate method. Both use a common method on FileUtils.
> <jmh.patch>