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

Run Enso tests with assertions enabled #7882

Merged

Conversation

Akirathan
Copy link
Member

@Akirathan Akirathan commented Sep 25, 2023

Closes:

Pull Request Description

This PR removes most of the Enso homemade Proxy functionality in EpbLanguage. Rather than that is uses new features in GraalVM that allow access to OtherContextTruffleObject. That fixes various assert checks in EpbLanguage and runtime-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:

  • All code follows the
    Scala,
    Java,
    style guides.
  • All code has been tested:
    • Unit tests have been written where possible.

@Akirathan Akirathan self-assigned this Sep 25, 2023
@Akirathan Akirathan added the CI: No changelog needed Do not require a changelog entry for this PR. label Sep 25, 2023
@Akirathan
Copy link
Member Author

Akirathan commented Sep 25, 2023

Encountered AssertionErrors in https://github.com/enso-org/enso/actions/runs/6297283538/job/17093926525?pr=7882:

GitHub
Hybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.

@Akirathan Akirathan mentioned this pull request Sep 26, 2023
5 tasks
@Akirathan
Copy link
Member Author

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 runtime-with-polyglot> testOnly *RuntimeVisualizationsTest -- -z [1], or runtime-with-polyglot> withDebug --debugger testOnly -- *RuntimeVisualizationsTest -- -z [1]. I have tried to do a global lock of EpbContext but with no success.

cc @JaroslavTulach

@JaroslavTulach
Copy link
Member

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 runtime-with-polyglot> testOnly *RuntimeVisualizationsTest -- -z [1], or runtime-with-polyglot> withDebug --debugger testOnly -- *RuntimeVisualizationsTest -- -z [1].

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 getSeenThreads():

Thread[#43,pool-1-thread-1-ScalaTest-running-RuntimeVisualizationsTest,5,main]=com.oracle.truffle.polyglot.PolyglotThreadInfo@64dd5b37[thread=Thread[#43,pool-1-thread-1-ScalaTest-running-RuntimeVisualizationsTest,5,main], enteredCount=0, cancelled=false, leaveAndEnterInterrupted=false], 

Thread[#66,sequential-command-pool-1,5,main]=com.oracle.truffle.polyglot.PolyglotThreadInfo@7ec8efc7[thread=Thread[#66,sequential-command-pool-1,5,main], enteredCount=1, cancelled=false, leaveAndEnterInterrupted=false], 

Thread[#65,job-pool-1,5,main]=com.oracle.truffle.polyglot.PolyglotThreadInfo@61cd1f20[thread=Thread[#65,job-pool-1,5,main], enteredCount=1, cancelled=false, leaveAndEnterInterrupted=false]}

that block access to JavaScript (which claims to be single threaded). If there was just a single thread, the JavaScript initialization would succeed.

Copy link
Member

@JaroslavTulach JaroslavTulach left a 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.

@JaroslavTulach
Copy link
Member

running std libs benchmarks to verify influence of such change on startup.

Previous benchmarks timed out (on endless loop in Sieve's Java_Script_Filter test involving is_same_object - e.g 3fa992a). New run scheduled.

@@ -161,7 +160,7 @@ case object GenerateMethodBodies extends IRPass {
case lam @ Function.Lambda(_, body, _, _, _, _)
if findForeignDefinition(
body,
lang = Some(ForeignLanguage.JS)
lang = Some("js")
Copy link
Contributor

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?

Copy link
Member

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.

@TruffleLanguage.Registration(
id = ForeignLanguage.ID,
id = "epb",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EpbLanguage constant?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needless. There is only one use of such a constant. Others are in modules that don't compile against this module:

image

They wouldn't be able to use the constant anyway. The fact that this all holds together is ensured by tests.

if (iop.hasMetaObject(res)) {
var meta = iop.getMetaObject(res);
var name = iop.getMetaQualifiedName(meta);
if ("module".equals(name)) {
Copy link
Contributor

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 ?

Copy link
Member Author

@Akirathan Akirathan left a 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.

@JaroslavTulach
Copy link
Member

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 -ea now and you may need to turn it on locally to see the same failure!

Comment on lines -10 to 9
/**
* 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(
Copy link
Member

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?

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

@jdunkerley jdunkerley left a 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.

@JaroslavTulach
Copy link
Member

Another benchmarks run scheduled just to be sure - no problems expected however.

@JaroslavTulach JaroslavTulach force-pushed the wip/akirathan/5585-Enable-Assertions-in-Enso-Tests branch from a7d18c0 to 61422e0 Compare December 15, 2023 11:25
@JaroslavTulach JaroslavTulach merged commit 4b65e44 into develop Dec 15, 2023
29 of 30 checks passed
@JaroslavTulach JaroslavTulach deleted the wip/akirathan/5585-Enable-Assertions-in-Enso-Tests branch December 15, 2023 12:31
assertEquals(12, res2.getArrayElement(2).asInt());
}

@Ignore
Copy link
Member

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 @Ignored right now.

Copy link
Member

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...

@JaroslavTulach
Copy link
Member

Looks like we have a significant regression in Sieve_Java_Script_Filter benchmark:

Sieve_Java_Script_Filter

Caused by something in between b5c995a...940b8f7 and the most likely cause is this PR. Alas.

Sieve_Java_Script_Natural benchmark hasn't regressed, so the cause isn't switching from Enso to JavaScript (done a lot to increment a number in the Sieve_Java_Script_Natural benchmark), but probably accessing JavaScript objects from Enso (which is what Sieve_Java_Script_Filter does).

@JaroslavTulach JaroslavTulach mentioned this pull request Jan 11, 2024
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: Clean build required CI runners will be cleaned before and after this PR is built. CI: No changelog needed Do not require a changelog entry for this PR.
Projects
None yet
7 participants