RFR: JDK-8033210: Intermittent build failure: jdk8 fails on win_i586 in jdk/make (p11_convert.c(67) : Cannot open 'sun_security_pkcs11_wrapper_PKCS11.h)

Tim Bell tim.bell at oracle.com
Wed Feb 5 15:32:06 UTC 2014


Hi Erik

Looks good to me as well.

Tim

> Looks good to me.
>
> /Magnus
>
> On 2014-02-05 11:35, Erik Joelsson wrote:
>> Hello,
>>
>> This change is intended for jdk8u (and jdk9).
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8033210/webrev.root.01/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8033210
>>
>>
>> Background:
>> In make/common/JavaCompilation.gmk, in the macro 
>> SetupJavaCompilation, we use the (new) -h feature in javac, which 
>> makes javac automatically run javah on classes with native methods. A 
>> problem is that javac will always print these headers, regardless of 
>> if they are there already or if they changed. To only cause 
>> recompilation of native code when something actually changed, there 
>> is logic in the macro to generate the headers to a temporary 
>> directory and then compare the output to any existing header files in 
>> the actual headers directory, and then only copy it over if it has 
>> changed. The temporary directory is then deleted.
>>
>> What I suspect is happening here is that, since the name of the 
>> temporary directory is only a function of the name of the actual 
>> header files directory, each call to SetupJavaCompilation, which 
>> points to a common header files directory, will use the same 
>> temporary directory. There is potential for a race if these execute 
>> in parallel. On windows, there are a couple of extra calls to 
>> SetupJavaCompilation that will execute in parallel, which is why this 
>> happens there and not on any other platforms.
>>
>> The fix is pretty simple. Make sure the temporary directory name is 
>> unique for each call to SetupJavaCompilation.
>>
>> /Erik
>




More information about the build-dev mailing list