-
Notifications
You must be signed in to change notification settings - Fork 316
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
Run Enso tests with assertions enabled #7882
Run Enso tests with assertions enabled #7882
Conversation
Encountered AssertionErrors in https://github.com/enso-org/enso/actions/runs/6297283538/job/17093926525?pr=7882:
|
lib/scala/bench-processor/src/main/java/org/enso/benchmarks/processor/BenchProcessor.java
Outdated
Show resolved
Hide resolved
…nso-Tests # Conflicts: # lib/scala/bench-processor/src/main/java/org/enso/benchmarks/processor/BenchProcessor.java
As of today, I am abandoning the PR once again. I am now stuck on Multi-threaded access requested by thread ... but is not allowed for js. I have pushed my latest investigation in 09fa463 that contains some testing instruments that might be useful. The simplest way to reproduce the error is just with |
I can simulate the failure. According to last week's discussion with @4e6 - there should be no multi-threaded access to the context. Yet there is. Here is the list of the three
that block access to JavaScript (which claims to be single threaded). If there was just a single thread, the JavaScript initialization would succeed. |
engine/runtime-language-epb/src/main/java/org/enso/interpreter/epb/node/ForeignEvalNode.java
Show resolved
Hide resolved
…instruments project
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fine with the changes. Please review as well. Once the CI gets stable, I'd like to integrate.
Previous benchmarks timed out (on endless loop in Sieve's |
@@ -161,7 +160,7 @@ case object GenerateMethodBodies extends IRPass { | |||
case lam @ Function.Lambda(_, body, _, _, _, _) | |||
if findForeignDefinition( | |||
body, | |||
lang = Some(ForeignLanguage.JS) | |||
lang = Some("js") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we keep that as a constant somewhere, please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Too much overhead to do so. We would need a new project sharable between all that were using ForeginLanguage.JS
. But I want to get rid of the heavyweight polyglot-api
dependency (in EpbLanguage
at least). I don't want to create new project just to host js
constant.
Btw. the real constant is defined in graal-js
and we don't compile against such module. E.g. there was never any guarantee (except tests) that we are using the right constant.
engine/runtime-language-epb/src/main/java/org/enso/interpreter/epb/EpbContext.java
Outdated
Show resolved
Hide resolved
engine/runtime-language-epb/src/main/java/org/enso/interpreter/epb/EpbContext.java
Outdated
Show resolved
Hide resolved
@TruffleLanguage.Registration( | ||
id = ForeignLanguage.ID, | ||
id = "epb", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EpbLanguage
constant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
engine/runtime-language-epb/src/main/java/org/enso/interpreter/epb/EpbLanguage.java
Outdated
Show resolved
Hide resolved
engine/runtime-language-epb/src/main/java/org/enso/interpreter/epb/ForeignEvalNode.java
Outdated
Show resolved
Hide resolved
if (iop.hasMetaObject(res)) { | ||
var meta = iop.getMetaObject(res); | ||
var name = iop.getMetaQualifiedName(meta); | ||
if ("module".equals(name)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we can't use iop.isNull
?
...glot/src/test/java/org/enso/interpreter/test/instrument/VerifyJavaScriptIsAvailableTest.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. Would be nice to get rid of some hardcoded strings though.
engine/runtime/src/main/scala/org/enso/interpreter/runtime/IrToTruffle.scala
Show resolved
Hide resolved
engine/runtime/src/main/java/org/enso/interpreter/runtime/EnsoContext.java
Show resolved
Hide resolved
engine/runtime-language-epb/src/main/java/org/enso/interpreter/epb/EpbContext.java
Outdated
Show resolved
Hide resolved
engine/runtime-language-epb/src/main/java/org/enso/interpreter/epb/JsForeignNode.java
Outdated
Show resolved
Hide resolved
...glot/src/test/java/org/enso/interpreter/test/instrument/VerifyJavaScriptIsAvailableTest.java
Outdated
Show resolved
Hide resolved
There is a failure in Table_Tests which can be simulated locally as: enso$ JAVA_OPTS=-ea ./built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/bin/enso --in-project test/Table_Tests --run test/Table_Tests/src/Common_Table_Operations/Date_Time_Spec.enso Don't forget that the CI runs with |
/** | ||
* An internal language that serves as a bridge between Enso and other supported languages. | ||
* | ||
* <p>Truffle places a lot of emphasis on safety guarantees, which also means that single-threaded | ||
* languages cannot easily be called from multiple threads. We circumvent this by using two separate | ||
* {@link com.oracle.truffle.api.TruffleContext}s, one (often referred to as "outer") is allowed to | ||
* run Enso, Host Java, and possibly other thread-ready languages. Languages that cannot safely run | ||
* in a multithreaded environment are relegated to the other context (referred to as "inner"). The | ||
* inner context provides a GIL capability, ensuring that access to the single-threaded languages is | ||
* serialized. | ||
* | ||
* <p>This imposes certain limitations on data interchange between the contexts. In particular, it | ||
* is impossible to execute origin language's code when executing in the other context. Therefore | ||
* outer context values need to be specially wrapped before being passed (e.g. as arguments) to the | ||
* inner context, and inner context values need rewrapping for use in the outer context. See {@link | ||
* org.enso.interpreter.epb.runtime.PolyglotProxy} and {@link ContextRewrapNode} for details of how | ||
* and when this wrapping is done. | ||
* | ||
* <p>With the structure outlined above, EPB is the only language that is initialized in both inner | ||
* and outer contexts and thus it is very minimal. Its only role is to manage both contexts and | ||
* provide context-switching facilities. | ||
*/ | ||
/** An internal language that serves as a bridge between Enso and other supported languages. */ | ||
@TruffleLanguage.Registration( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this whole block of documentation removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done by @Akirathan, but I'd say it no longer reflects reality. Times changed and we no longer have to implement this ourselves, but rather rely on Truffle to do it for us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw. @kustosz asked why do we need this EpbLanguage
anymore? True, possibly we could do without it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just reviewed the enso files.
Another benchmarks run scheduled just to be sure - no problems expected however. |
a7d18c0
to
61422e0
Compare
assertEquals(12, res2.getArrayElement(2).asInt()); | ||
} | ||
|
||
@Ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reported oracle/graal#8033 to describe why this test has to be @Ignore
d right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With onDeniedThreadAccess
as proposed by oracle/graal#8266 we have a way to act like an Ethernet on collision and successfully orchestrate the two threads accessing the same context to run into completion.
More info on Ethernet collision detection and behavior - most important "Calculate and wait the random backoff".
Continue discussion at...
Looks like we have a significant regression in Sieve_Java_Script_Filter benchmark: Caused by something in between b5c995a...940b8f7 and the most likely cause is this PR. Alas.
|
Closes:
GenericForeignNode
Pull Request Description
This PR removes most of the Enso homemade
Proxy
functionality inEpbLanguage
. Rather than that is uses new features in GraalVM that allow access toOtherContextTruffleObject
. That fixes variousassert
checks inEpbLanguage
andruntime-with-polyglot
tests. Now the whole Enso system can be executed with-ea
checks on.Important Notes
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,
style guides.