New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8292758: put support for UNSIGNED5 format into its own header file #10067
Conversation
👋 Welcome back jrose! A progress list of the required criteria for merging this PR into |
@rose00 this pull request can not be integrated into git checkout compressed-stream
git fetch https://git.openjdk.org/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push |
67af6b1
to
e938b01
Compare
This code passes tiers 1,2,3. |
Webrevs
|
@rose00 Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See OpenJDK Developers’ Guide for more information. |
The new header file presents the encoding algorithm by means of templates.
Defaults are set in such a way that any C++ types that natively support In addition, there are small "gadgets" for reading a series of ints from a buffer, writing a series to a buffer, and sizing a series (which is faster than writing or reading). These are not yet used. However, prototyping of further use cases for this compression (particularly, |
const int min_expansion = UNSIGNED5::MAX_LENGTH; | ||
if (nsize < min_expansion*2) | ||
nsize = min_expansion*2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not clear if this is needed or just an optimization. Maybe add a comment. Also, using MAX2 might be clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm concerned about the "excluded bytes" change. It appears to change the encoding, which would mean that SA would not be able to read streams from earlier JVMs, which may or may not be a concern. I suggest splitting this up into the straight-forward refactor (without the excluded bytes change), then adding excluded bytes as a follow-up.
Yes, that is a slight change. Splitting is not necessary for the reason you mention because this PR includes SA changes. This SA change is tested by several jtreg tests: That is, injecting bugs causes SA tests to fail, and fixing them fixes the tests. This is the case because the compressed stream data structure is used for all stack walking. So if there's a bug, we find it immediately. And the same is true for SA unit tests which peform stack walking. Net result: It's safe, there is no bug, because testing coverage is robust. The math of the encoding is the same whether there are 255 or 256 byte values available, so the adjustment is very low risk. (The math works for any underlying byte type or size; we choose 8-bit bytes excluding nulls to provide 255 distinct tokens.) The benefit is that the encoding can be accompanied by null termination, which enhances debuggability and resilience against bad counts and bad pointers. |
Wouldn't the SA stack walk fail when attaching to a core dump from an earlier JVM that does not exclude nulls? |
I'm not sure how important compatibility is with older JVMs. SA is capable of (if properly maintained) connecting to any JVM. You'll see signs of that in the code:
However, attempts like this one are ancient, and certainly this one should be removed. There's probably a 100 other reasons why attaching to a 1.5 JVM won't work. We don't do any compatibility testing with older JVMs. For the most part I'd say SA users should always match SA with the version of the JVM they are targeting. I'd be interested in hearing if anyone feels otherwise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for adding the SA and debug.cpp for debugging this.
|
||
// T.I.L. | ||
// $ sh ./configure ... --with-gtest=<...>/googletest ... | ||
// $ make exploded-test TEST=gtest:unsigned5 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does T.I.L mean? This isn't the only way to run this test, so don't include this.
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/Unsigned5.java
Outdated
Show resolved
Hide resolved
} | ||
|
||
// returns the encoded byte length of an unsigned 32-bit int | ||
static constexpr int encoded_length(uint32_t value) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should all of these functions be private?
Writer(const ARR& array) | ||
: _array(const_cast<ARR&>(array)), _limit_ptr(NULL) | ||
// note: if _limit_ptr is NULL, the ARR& is never reassigned | ||
{ limit_init(); _position = 0; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indent needed.
…emove vmStructs coupling from SA
|
||
// reports the largest uint32_t value that can be encoded using len bytes | ||
// len must be in the range [1..5] | ||
static constexpr uint32_t max_encoded_in_length(uint32_t len) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few of the classes make the gtest test a friend so that functions that are internal to unsigned5 can be made private. The test would have to call these functions in a class though, and not directly in the test cases. Maybe this is ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, for the current CompressedStream and for upcoming changes.
@rose00 This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 78 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
@dean-long and @coleenp Thank you for the reviews. The public functions in Testing notes: This change passes a targeted test that runs It also passes tiers 1/2/3 (in a slightly earlier version) and all gtests (in the latest version). |
/integrate |
Going to push as commit 8d3399b.
Your commit was automatically rebased without conflicts. |
Refactor code from inside of CompressedStream into its own unit.
This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams).
Add gtests.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10067/head:pull/10067
$ git checkout pull/10067
Update a local copy of the PR:
$ git checkout pull/10067
$ git pull https://git.openjdk.org/jdk pull/10067/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 10067
View PR using the GUI difftool:
$ git pr show -t 10067
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10067.diff