RFR(XL): 8167108 - SMR and JavaThread Lifecycle
Erik Österlund
erik.osterlund at oracle.com
Wed Nov 22 09:07:30 UTC 2017
Hi,
Some replies...
On 2017-11-21 17:28, Daniel D. Daugherty wrote:
> Hi Coleen!
>
> Thanks for making time to review the Thread-SMR stuff again!!
>
> I have added back the other three OpenJDK aliases... This review is
> being done on _four_ different OpenJDK aliases.
>
> As always, replies are embedded below...
>
>
> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote:
>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.cpp.html
>>
>>
>> 32 ThreadsList::ThreadsList(int entries) : _length(entries),
>> _threads(NEW_C_HEAP_ARRAY(JavaThread*, entries + 1, mtGC)),
>> _next_list(NULL) {
>>
>> Seems like it should be mtThread rather than mtGC.
>
> Fixed. Definitely an artifact of Erik's original prototype when he
> extracted Thread-SMR from his GC work... Thanks for catching it.
>
Confirmed. At the time I considered the Threads list overheads GC
overheads, but I agree mtThread is a better fit today.
>
>>
>> + return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u);
>>
>> Can you add a comment about where this number came from?
>
> I'll have to get that from Erik...
Wow, that looks like code I wrote a *very* long time ago. :) That is a
variation of Knuth's multiplicative hash which is outlined in a comment
in synchronizer.cpp and referred to in that comment as a phi-based
scheme. Basically the magic number is 2^32 * Phi (the golden ratio),
which happens to be a useful value for building a reasonably simple yet
pretty good hash function. It is not the optimal hash function, but
seemed to definitely be good enough for our purposes.
Thanks,
/Erik
More information about the serviceability-dev
mailing list