jdk
                                
                                
                                
                                    jdk copied to clipboard
                            
                            
                            
                        8292022: Issues caused by Unary Plus Operator + and Shift Operators priority
(capacity + capacity>>1) The result of this expression is still capacity. So I guess what the author thought at the time might be (capacity + (capacity >> 1)), see https://bugs.openjdk.org/projects/JDK/issues/JDK-8292022
Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
 - [x] Change must not contain extraneous whitespace
 - [x] Commit message must refer to an issue
 
Issue
- JDK-8292022: Issues caused by Unary Plus Operator + and Shift Operators priority
 
Reviewing
Using git
Checkout this PR locally: 
$ git fetch https://git.openjdk.org/jdk pull/9698/head:pull/9698 
$ git checkout pull/9698
Update a local copy of the PR: 
$ git checkout pull/9698 
$ git pull https://git.openjdk.org/jdk pull/9698/head
Using Skara CLI tools
Checkout this PR locally: 
$ git pr checkout 9698
View PR using the GUI difftool: 
$ git pr show -t 9698
Using diff file
Download this PR as a diff file: 
https://git.openjdk.org/jdk/pull/9698.diff
Hi @GGGGGHT, welcome to this OpenJDK project and thanks for contributing!
We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.
If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user GGGGGHT" as summary for the issue.
If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.
@GGGGGHT The following label will be automatically applied to this pull request:
compiler
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.
/signed
Thank you! Please allow for up to two weeks to process your OCA, although it is usually done within one to two business days. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!
Hi, please send me an e-mail at [email protected] so that I can verify your account's OCA.
Hi, please send me an e-mail at [email protected] so that I can verify your account's OCA.
I have sent the mail
I don't see a reason to over-allocate the 1.5x sized ByteBuffer here. So, if we just drop to
ByteBuffer.allocate(capacity)`, it would still resolve the problem, leave the current behavior as it is (obviates the need for deeper testing), and would make more sense anyway. Right?
Maybe so, but I think direct allocation of 1.5x size may reduce the number of allocations in some extreme cases.
Maybe so, but I think direct allocation of 1.5x size may reduce the number of allocations in some extreme cases.
On the other hand, it might also waste memory in general case? I think status quo behavior is okay, and we can just change the code to match it.
Maybe so, but I think direct allocation of 1.5x size may reduce the number of allocations in some extreme cases.
On the other hand, it might also waste memory in general case? I think status quo behavior is okay, and we can just change the code to match it.
You are right, I have re-modified this code.
@GGGGGHT This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!
@GGGGGHT This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.