I'm confused about this issue. My initial take was that this was caused by 8004151 because the files in the repo were not sorted, while the generated file was.

Based on the changeset:

http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/57d5d9544628

I see:

+       $(GENSRC_X11WRAPPERS_TMP)/sizer.$*.exe | $(SORT) > $@.tmp

but this:

+long 4
+int 4
+short 2
+ptr 4
+Bool 4
+Atom 4
+Window 4
+XExtData.number 0
...

does not appear sorted to me.

David H.
-------

On 29/01/2013 6:41 AM, David Chase wrote:

On 2013-01-25, at 4:55 PM, Kelly O'Hair<kelly.oh...@oracle.com>  wrote:

Please file JBS Issues.

So this is a new bug that needs filing?  I think it's sort of a duplicate, see 
below.

And keep in mind every "Solaris 10" system could be different.

Solaris 10 10/09 s10x_u8wos_08a X86
Builds with jdk8, fails with jdk7.

I am pretty sure that the cause of the bug is a dependence (in 
WrapperGenerator) on the order in which items are iterated out of a hash table. 
 That appears to have changed in the transition from jdk7 to jdk8.  That change 
was apparently necessary to make it (very much) harder to DOS a hashtable with 
collisions.  I observed different output running WrapperGenerator with the 
exact same inputs under 7 and 8, cutting and pasting from a build and replacing 
only the target directory and the host VM.

It seems to be fixed in jdk8-build as of six days ago (I checked), as a 
side-effect of fixing 8004151

David

Reply via email to