JDK-6735522 : Bitmap - force inlining of find_next_one_bit()
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs14
  • Priority: P3
  • Status: Resolved
  • Resolution: Other
  • OS: generic
  • CPU: generic
  • Submitted: 2008-08-08
  • Updated: 2018-11-02
  • Resolved: 2018-11-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 12
12Resolved
Related Reports
Relates :  
JDK-8179181 - Cleanup BitMap search API
Relates :  
JDK-6735527 - Bitmap - speed up searches
Description
A user reported that full gc times with parallel compaction improved significantly (up to 20%) when compiler directives were used to force the method BitMap::find_next_one_bit() to be inlined.  The method is already declared inline, but at least one compiler (gcc) does not inline it because it is too big and/or it contains a loop.
Comments
After JDK-6735527, neither "get_next_(one|zero)_offset" nor "find_obj_(beg|end)" show up in the above searches on linux-x64 fastdebug or release builds. Before JDK-6735527, find_obj_beg showed up in psParallelCompact.o. Resolving this as having been addressed by JDK-6735527.
02-11-2018
To find not-inlined calls, cd to the build's libjvm/objs directory and execute this command: for f in *.o do if `objdump -t $f | egrep -q "get_next_(one|zero)_offset"` then echo $f fi done In a linux-x64 product build, the only reported file is c1_LinearScan.o. Searching for "find_obj_(beg|end)" finds psParallelCompact.o, which is the complaint from the 2008-08-08 comment.
22-04-2017
Doing some more source control archeology, the initial G1 integration removed find_next_one_bit and added declared-inline get_next_one_offset_inline[_aligned_right] and get_next_zero_offset_inline (no _aligned_right variant as not needed). It also declared get_next_{zero,one}_offset inline. This makes the naming situation rather confusing. We could drop the _inline suffixes and drop the old non-suffixed variants. Also look at callers of them, and of ParMarkBitMap::find_obj_{beg,end}, and verify the desired inlining is occurring.
22-04-2017
Maybe there's been a name change since this was reported. The current function name is get_next_one_offset. There is also get_next_one_offset_inline[_aligned_right] (added as part of the initial integration of G1, but surprisingly only used by parallel gc). The latter two would be candidates for always_inline, if still needed to actually get them to be inlined - we're using much more recent compiler versions now. So we should see if these are already being inlined, and if so, close this.
03-07-2015
EVALUATION find_next_one_bit() is used heavily by par compaction when updating pointers; it is called at least once for each reference in the heap that does not point into the dense prefix. The reported experiment used the gcc directive __attribute__((always_inline)) to force inline of find_next_one_bit(). It's not clear that it should be inlined at every call site; most likely only the call sites used heavily by par compaction should force inlining.
08-08-2008