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