Skip to content

Propagate JRUBY_OPTS from parent env when running mspec - #9643

Open
headius wants to merge 1 commit into
jruby:jruby-10.0from
headius:mspec_propagate_jruby_opts
Open

Propagate JRUBY_OPTS from parent env when running mspec#9643
headius wants to merge 1 commit into
jruby:jruby-10.0from
headius:mspec_propagate_jruby_opts

Conversation

@headius

@headius headius commented Sep 3, 2026

Copy link
Copy Markdown
Member

We need to be able to manipulate the mspec jobs by setting JRUBY_OPTS, as described in #9597, but the old logic here overwrote that environment variable while setting up the subprocess launch. This change builds the new JRUBY_OPTS starting with the current environment, so additional flags can be passed through.

This is not ideal; a rogue JRUBY_OPTS in the parent env could cause these jobs to run in ways that break their verification. Unfortunately rake provides few ways to parameterize tasks, so we are forced to permute and generate all tasks we wish to see, and ENV is the cleanest way to pass in additional tweaks.

Fixes #9597

@headius
Propagate JRUBY_OPTS from parent env when running mspec
4f9197a 
We need to be able to manipulate the mspec jobs by setting
JRUBY_OPTS, as described in jruby#9597, but the old logic
here overwrote that environment variable while setting up the
subprocess launch. This change builds the new JRUBY_OPTS starting
with the current environment, so additional flags can be passed
through.

This is not ideal; a rogue JRUBY_OPTS in the parent env could cause
these jobs to run in ways that break their verification.
Unfortunately rake provides few ways to parameterize tasks, so we
are forced to permute and generate all tasks we wish to see, and
ENV is the cleanest way to pass in additional tweaks.

Fixes jruby#9597
@headius headius mentioned this pull request Sep 3, 2026
Draft
@headius

headius commented Sep 3, 2026

Copy link
Copy Markdown
Member Author

I'll work through the regressions in non-indy mode before merging.

@headius

headius commented Sep 3, 2026

Copy link
Copy Markdown
Member Author

First failure I'm looking at:

Integer#dup returns self for large integers FAILED
Expected 4611686018427387905 to be identical to 4611686018427387905

This appears to be due to the IR compiler propagating some literal values into their use sites.

The IR looks like this right before JIT for i = ... ; p i.object_id; p i.dup.object_id:

BB [2:LBL_1:-1] -EXIT->3
	%self = recv_self()
	%v_0 = recv_kw()
	check_arity(%v_0 ;req: 0, opt: 0, *r: false)
	line_num(;n: 0, coverage: false, oneshot: false)
	i = copy(Fixnum:4611686018427387905)
	%v_2 = call_0o(Fixnum:4611686018427387905 ;n:object_id, t:NO, cl:false)
	%v_1 = call_1o(%self, %v_2 ;n:p, t:FU, cl:false)
	%v_4 = call_0o(i ;n:dup, t:NO, cl:false)
	%v_5 = call_0o(%v_4 ;n:object_id, t:NO, cl:false)
	%v_3 = call_1o(%self, %v_5 ;n:p, t:FU, cl:false)
	return(%v_3)

Note that the first call to object_id has inlined the integer value.

@headius

headius commented Sep 3, 2026

Copy link
Copy Markdown
Member Author

Odd thing about this is that the indy compiler also shows different object_id, so it is not normalizing all propagated values to the same object either.

@headius headius mentioned this pull request Sep 10, 2026
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

See More

Successfully merging this pull request may close these issues.

1 participant

@headius