RFR(XXS) 8213948 Solaris-X64 build fails with compact hashtable

Aleksey Shipilev shade at redhat.com
Sat Nov 17 10:51:29 UTC 2018


On 11/17/2018 04:17 AM, Ioi Lam wrote:
> On 11/16/18 6:16 PM, Aleksey Shipilev wrote:
>> On 11/17/2018 02:50 AM, Ioi Lam wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8213948
>>> http://cr.openjdk.java.net/~iklam/jdk12/8213948-solaris-x64-compact-hashtable-build.v01/
>> Looks good.
>>
>> Can anyone hazard a guess *why* this helps? Does that just makes compiler happier about using this
>> function pointer as template parameter a few lines below? Is it Solaris compiler bug that does not
>> put non-inline read_value_from_compact_hashtable into symbol table, even though it is used as
>> template parameter?
> 
> I guess it's a compiler (or linker) bug. The solaris/x64 compiler has no problem with
> ResourceHashtable that has a similar pattern:
> 
> template<typename K> unsigned primitive_hash(const K& k) {
>   unsigned hash = (unsigned)((uintptr_t)k);
>   return hash ^ (hash >> 3);
> }
> template<
>     typename K, typename V,
>     unsigned (*HASH)  (K const&)           = primitive_hash<K>,
>     ....
>     >
> class ResourceHashtable {...}
> 
> However, in my case, I am declaring a new template class (OffsetCompactHashtable) that subclasses
> anther template class (CompactHashtable). The solaris compiler seems to choke on too many levels of
> templates .... :-(
> 
> As noted in the bug report, removing "-Wl,-z,defs" from LDFLAGS fixes the problem. The compiler
> probably tags the non-inlined functions incorrectly so they were garbage collected by the linker.

Sounds reasonable, thanks!

-Aleksey




More information about the hotspot-runtime-dev mailing list