Generated compiler command file overrides user specified compiler command file

[Nitsan Wakart]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jmh.patch
Type: text/x-patch
Size: 8154 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/jmh-dev/attachments/20140528/c92cb66f/jmh.patch>