Reference to a document in the sources
john.r.rose at oracle.com
Wed Jun 13 16:45:14 UTC 2018
On Jun 13, 2018, at 9:35 AM, Andrew Dinn <adinn at redhat.com> wrote:
> On 13/06/18 15:11, John Rose wrote:
>> A blast from the past! I posted a copy (sampled circa JDK 1.4.2) here:
>> http://cr.openjdk.java.net/~jrose/jvm/checktype-2001.txt <http://cr.openjdk.java.net/~jrose/jvm/checktype-2001.txt>
> Oooh, very nice! I am glad (and not at all surprised) to see this stuff
> was indeed based on a written spec backed up by careful testing. I could
> have done with seeing this doc a year ago before I started trying to
> work it all out from the code ;-)
The design has worn well over the years. There is one serious
flaw that I am aware of: In certain unusual workloads, the secondary
supertype cache will thrash, *and* multiple threads will thrash it.
This leads to a slowdown from cache line motion, which is more
noticeable than just the slowdown from repeatedly linear-searching
the supertype array.
I think there's some Scala workload out there that shows this, when
many threads iterate over a list of objects testing each object against
two (or more) different interfaces. That will continually refill the SSC.
The solution would be to throttle updates to the secondary supertype
cache if they become very frequent, or (and now I'm dreaming) if the
processor can detect too many RTO events on the cache line.
This would be a good project for someone to take on. The bug is:
More information about the hotspot-runtime-dev