Skip to content
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

document tr.jit options #33

Closed
gireeshpunathil opened this issue Sep 16, 2017 · 3 comments
Closed

document tr.jit options #33

gireeshpunathil opened this issue Sep 16, 2017 · 3 comments
Labels

Comments

@gireeshpunathil
Copy link
Contributor

It would be worthwhile to document the hidden treasures of trjjit optimizations (a significant portion of j9options.cpp) for:

  • Users to gain insight into the (so far) under-documented tr jit features, take advantage of it by applying fine grained compiler customizations based on the specific environment and workload.
  • Community members to better acquiant with the optimizations, hack around with the code with ease, get upto speed for large scale collaboration.
@gireeshpunathil
Copy link
Contributor Author

I propose to have this format:

optimization name
usage:
meaning:
(optional) code sample:
caveat / side effect / caution:
link to any literature on the underlying optimization:

I am happy to get started / involed. Please 👍 on this to join this initiative.

@0xdaryl
Copy link
Contributor

0xdaryl commented Sep 17, 2017

Great initiative! You are actually suggesting two important efforts here: the documentation of optimizations themselves, and the documentation of control knobs to allow finer grain control of those optimizations and many other aspects of the J9 JIT.

The Eclipse OMR project has begun to document optimizations where it can (it's an ongoing effort). Many of these optimizations are leveraged directly or extended by OpenJ9. The goal there is to provide as much documentation as close to the actual source code as possible. I think a similar effort as you propose for OpenJ9 is important too, and will set the proper context for documenting many of the J9Option knobs that control them.

For documenting the internal options, because many of them are fleeting or experimental I'd say its important to keep their documentation as close to the code as possible as well to ensure they stay current. Also, be aware that the JIT does make use of environment variables (usually queried with calls to feGetEnv) to guard and control some features as well. These are even more undocumented than J9Options (!) and often guard experimental and debug code, or are used in places in the JIT where an Options object is not available.

gireeshpunathil added a commit to gireeshpunathil/openj9 that referenced this issue Sep 20, 2017
…ch as

possible with the help of a sample code. Build incrementally,
if possible by wider set of contributors, through squash and merge.

Fixes: eclipse-openj9#33

Signed-off-by: Gireesh Punathil <[email protected]>
@DanHeidinga
Copy link
Member

Closing this as there has been no action in many months and the suggested direction has been to document the options directly in the code.

fjeremic pushed a commit to fjeremic/openj9 that referenced this issue Mar 2, 2018
Revert "Add methods inherited from superinterfaces to iTables"
tajila pushed a commit to tajila/openj9 that referenced this issue Aug 6, 2019
* Fix Object References:

- fixup object refs for classes found inside hashtable
- two pathways related to jcldefine and resolvesupport
- created function initializeImageClassObject

Signed-off-by: akshayben <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants