MethodData::bci_to_dp and ciMethodData::bci_to_data show up in startup/warmup profiles - much of the overhead allocating resource objects when iterating over ProfileData objects (next_data)
Since most of the ProfileData block a static size determined by their DataLayout tag, providing a means to iterate over the raw DataLayout objects allow us to avoid allocating resource objects for most of the types of ProfileData.
Experiments show this is very profitable - reducing overhead of MethodData::bci_to_dp by around 80-85% and ciMethodData::bci_to_data sometimes even more on a set of tests.
The former is called via the compilation policy on the java thread, which means it has a direct effect on startup.
Since most of the ProfileData block a static size determined by their DataLayout tag, providing a means to iterate over the raw DataLayout objects allow us to avoid allocating resource objects for most of the types of ProfileData.
Experiments show this is very profitable - reducing overhead of MethodData::bci_to_dp by around 80-85% and ciMethodData::bci_to_data sometimes even more on a set of tests.
The former is called via the compilation policy on the java thread, which means it has a direct effect on startup.