Closed nirvdrum closed 2 weeks ago
Do you have JT_SPECS_COMPILATION
or JT_SPECS_SPLITTING
set in the environment maybe?
These specs do seem to pass fine in our darwin-aarch64 CI.
I have JT_SPECS_COMPILATION
enabled. When I remove that, the specs pass even on JVM CE.
OK, that's kind of expected then since JT_SPECS_COMPILATION=false
does --engine.Splitting=false
(unless JT_SPECS_SPLITTING=true
).
So we should check that condition in the guard
then.
Ideally we would check specifically that splitting is enabled.
I think that might be possible by calling DirectCallNode#isCallTargetCloned()
on something we know we always-split like Array#[]
.
We could create a dummy DirectCallNode e.g. in CoreLibrary, call cloneCallTarget() and then if isCallTargetCloned() returns true it should mean splitting is enabled.
@andrykonchin Could you look into that?
Should be fixed in 5603e8bcf5e35813e5cdff36f455079cf2aa1bc8.
cc @nirvdrum
In local development I run with
JT_ENV=jvm-ce
. I recently pulled from master and found that I had 12 test failures that I didn't expect. I thought maybe that I had some stale data, but runningjt rebuild && jt test fast
didn't fix the problem. Then I tried running again withJT_ENV=jvm
and the test suite passed.I only see the problem on macOS ARM64. I tested on Linux x86_64 and did not see the problem. I haven't bisected, but I think it's likely that #3508 is when the issue was introduced.