Deprecate and isolate all Options that are no longer used#6315
Merged
headius merged 3 commits intojruby:masterfrom Sep 21, 2020
Merged
Deprecate and isolate all Options that are no longer used#6315headius merged 3 commits intojruby:masterfrom
headius merged 3 commits intojruby:masterfrom
Conversation
Most of these were completely unused. A few were still used but the features they referred to did not work anymore, or were otherwise nonnfunctional in some way. There's some related cleanup of RubyInstanceConfig here but I have not done a full audit of unused fields and methods there. At least a few of these may have meaning in the future, if the functionality they used to refer to is restored: * REFLECTED_HANDLES: we may want to add back reflected DynamicMethod handles to core class methods to support platforms that do not allow bytecode generation (e.g. GraalVM AOT). * FIBER_COROUTINES: The Loom project is moving fast and we will definitely take advantage of it. We will probably want a more Loom-specific property name at that time, though. * FFI_COMPILE_INVOKEDYNAMIC: We are not currently binding Ruby to FFI calls as directly as we could, and we should probably restore this functionality at some point. * THREAD_DUMP_SIGNAL: We used to register a trap for dumping all Ruby stack traces. We may want to restore this functionality. * ENUMERATOR_LIGHTWEIGHT: We may want to make it possible to turn off lightweight enumerators, of which we currently have none? Seems unlikely. * INVOKEDYNAMIC*: most of the capabilities of invokedynamic have been always-on (in indy mode) since they stabilized in Java 8, but being able to configure them at a finer grain may be useful in the future. * COMPILE*: as with INVOKEDYNAMIC*, most optimizations are always- on, and we may want to restore the ability to turn them off. This cleanup was inspired by jruby#1585.
I think this got removed when the reflected handle option got deprecated. Generated invokers do not have c_call/c_return trace events, so the fulltrace option check is still needed here.
Member
Author
|
The sole failure in the last build was a regression on master. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Most of these were completely unused. A few were still used but
the features they referred to did not work anymore, or were
otherwise nonnfunctional in some way.
There's some related cleanup of RubyInstanceConfig here but I have
not done a full audit of unused fields and methods there.
At least a few of these may have meaning in the future, if the
functionality they used to refer to is restored:
DynamicMethod handles to core class methods to support platforms
that do not allow bytecode generation (e.g. GraalVM AOT).
definitely take advantage of it. We will probably want a more
Loom-specific property name at that time, though.
FFI calls as directly as we could, and we should probably
restore this functionality at some point.
Ruby stack traces. We may want to restore this functionality.
off lightweight enumerators, of which we currently have none?
Seems unlikely.
been always-on (in indy mode) since they stabilized in Java 8,
but being able to configure them at a finer grain may be useful
in the future.
on, and we may want to restore the ability to turn them off.
This cleanup was inspired by #1585.