Date: Thu, 28 Mar 2024 20:34:17 +0000 (UTC) Message-ID: <2030672372.1209.1711658057359@34fc92c9345b> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1208_1205176072.1711658057358" ------=_Part_1208_1205176072.1711658057358 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page is deprecated and it's content is either old or being moved to= the OpenJDK Developers' Guide. Please update = your links.
In order to push a change to the HotSpot source code you need to complet= e all the steps in the list below. This is done in order to ensure code qua= lity and reduce the risk of introducing bugs into the code base.
There is a notion of tr= ivial changes that can be pushed sooner than 24 hours.= It should be clearly stated in the review mail that the intention is to pu= sh as a trivial change. How to actually define "trivial" is decided on a ca= se-by-case basis but in general it would be things like fixing a comment, o= r moving code without changing it. Backing out a change is also considered = trivial as the change itself in that case is generated by mercurial.
Please note that the submit repository will only run a set of smoke-test= s to ensure your change compiles and runs on a variety of platforms. It wil= l not do any targeted testing on the particular code you have changed. Runn= ing through the submit repository is only the minimum requirement. You must= also make sure your change works as expected before pushing using targeted= testing. Consider writing a few JTREG tests for your change, or some unit = tests using the GTest framework. Including the new tests (in the right plac= es) with your push to the submit repository will ensure your tests will be = run as part of your testing on all platforms and in the future. Look for ti= er1 in test/hotspot/jtreg/TEST.groups to see which tests and directori= es that are included in the submit repo testing.
NOTE: This section is out o= f date since the move to using Git and GitHub for the main OpenJDK developm= ent project.
Pushing a change is fairly straight forward. Make sure your commit has a= proper description. The JBS bug id and the Rewiewed-by lines are mandatory= .
8197844= : JVMTI GetLoadedClasses should use the Access API Summary: Make sure the holder of a class loader is accessed during iteratio= n of CLDG Reviewed-by: eosterlund, rkennke
Always make sure there are no new chan= ges in the repository you are pushing to before pushing
hg in
=
span> should return an empty set of changes when you push. Always verify th=
is the last thing you do! If there are new changes in there you must pull t=
hese changes and rebase your patch on top of these new changes. We use reba=
se to avoid merge changesets as we want to keep the mercurial history as li=
near as possible. This makes it easier to do binary searches through the hi=
story when trying to determine the cause of some changed behavior for insta=
nce (read debugging).
hg pull -u --rebase=
span>
Look through the new changes before you push your change. Did something = recently pushed conflict with your change? There may be a need to rerun som= e testing or at least recompile before pushing.
When you feel confident enough, push using hg push
.
As noted in the list above, you are expected to be around after having p= ushed a change in case there are any issues with it. A change that causes f= ailures in later tiers may be backed out if a fix can not be provided fast = enough, or if the developer is not responsive when noticed about the failur= e. Note that #7 above should be interpreted as "it is a really bad idea to = push a change the last thing you do before bedtime, or the day before going= on vacation".