InlineCacheBuffer + GuaranteedSafepointInterval (original) (raw)
Vitaly Davidovich vitalyd at gmail.com
Fri Jun 5 15:17:21 UTC 2015
- Previous message: InlineCacheBuffer + GuaranteedSafepointInterval
- Next message: InlineCacheBuffer + GuaranteedSafepointInterval
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Any words of wisdom? Thanks
sent from my phone On Jun 3, 2015 12:02 PM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:
Hi,
Could someone please explain the idea behind GuaranteedSafepointInterval induced safepoints being gated on InlineCacheBuffer::isempty() returning false? This code in safepoint.cpp: bool SafepointSynchronize::iscleanupneeded() { <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/runtime/safepoint.cpp#l479> // Need a safepoint if some inline cache buffers is non-empty <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/runtime/safepoint.cpp#l480> if (!InlineCacheBuffer::isempty()) return true; <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/runtime/safepoint.cpp#l481> return false; <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/runtime/safepoint.cpp#l482>}
Looking at icBuffer.cpp: void InlineCacheBuffer::updateinlinecaches() { <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/code/icBuffer.cpp#l146> if (buffer()->numberofstubs() > 1) { <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/code/icBuffer.cpp#l147> if (TraceICBuffer) { <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/code/icBuffer.cpp#l148> tty->printcr("[updating inline caches with %d stubs]", buffer()->numberofstubs()); <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/code/icBuffer.cpp#l149> } <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/code/icBuffer.cpp#l150> buffer()->removeall(); <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/code/icBuffer.cpp#l151> initnextstub(); <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/code/icBuffer.cpp#l152> } <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/code/icBuffer.cpp#l153> releasependingicholders(); <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/code/icBuffer.cpp#l154>} <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/1aef080fd28d/src/share/vm/code/icBuffer.cpp#l155>What exactly triggers IC holders to be eligible for deletion? The reason behind this question is I'd like to eliminate "unnecessary" safepoints that I'm seeing, but would like to understand implications of this with respect to compiler infrastructure (C2, specifically). I have a fairly large code cache reserved, and the # of compiled methods isn't too big, so space there shouldn't be an issue. Why is GuaranteedSafepointInterval based safepoint actually gated on this particular check? If I turn off background safepoints (i.e. GuaranteedSafepointInterval=0) or set them very far apart, am I risking stability problems, at least in terms of compiler? Thanks
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150605/7b4546b3/attachment-0001.html>
- Previous message: InlineCacheBuffer + GuaranteedSafepointInterval
- Next message: InlineCacheBuffer + GuaranteedSafepointInterval
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the hotspot-compiler-dev mailing list