WebAssembly and file upload to a module

[asiwecki (Adam Siwecki)]

I downgraded to 11.0.0.2681.

[mh (marc hoffman)]

@asiwecki

I downgraded to 11.0.0.2681.

Strange; i don’t believe anything major changed between those versions, for the Wasm debugger, or for VS2015 support specifically…

[asiwecki (Adam Siwecki)]

Just to let you know, the debugger problem in VS2015 remains on 11.0.0.2689. I’m attching the screenshots of the error messages: 1.png appears on the first attempt to start debugging, 2.png on every subsequent.
vs2015_wasm_debug.zip (9.5 KB)

[asiwecki (Adam Siwecki)]

@ck, please, be so kind and address these:

@asiwecki

1. The GC problem I recently reported doesn’t appear if I don’t manually call Collect. This leads to a conclusion that GC never collects anything if not forced to and that’s where the huge memory consumption comes from. When is GC expected to automatically collect?

2. I think I’ve already asked it somewhere above - is there any way to force disposal of a particular object? I’ve tried this SimpleGC.ForceRelease(IntPtr(InternalCalls.Cast(_obj))) but it doesn’t seem to get the job done.

[mh (marc hoffman)]

@asiwecki

Just to let you know, the debugger problem in VS2015 remains on 11.0.0.2689. I’m attching the screenshots of the error messages: 1.png appears on the first attempt to start debugging, 2.png on every subsequent.
vs2015_wasm_debug.zip (9.5 KB)

Ok, but i’d really encourage you to update to VS2017 or later, as we we’re no longer supporting VS2015.

[asiwecki (Adam Siwecki)]

Yes Marc, I will upgrade. I thought that VS2015 is supported as the Integrate with Visual Studio 2015 option still appears in the installer.

[mh (marc hoffman)]

@asiwecki

Yes Mark, I will upgrade. I thought that VS2015 is supported as the Integrate with Visual Studio 2015 option still appears in the installer.

It’s there for a handful (a single, really) of customers who still wanna build Silverlight projects, but we’re not testing or supporting it anymore, so it’s “use at your own risk”. (that said, i don’t see what/why Wasm debugging should have gotten broken for VS2015 only.

But since we can not reproduce the issue her eon VS2017 and later, the first step would be to upgrade.

[ck (Carlo Kok)]

I have to check. I want to dive into this tomorrow morning. You can’t really call SimpleGC.ForceRelease no, that will cause issues if there still is something that triggers a gc addref/release. I’ll try to get back to you tomorrow morning

[RemObjectsSoftware (RemObjects)]

bugs://E25500 was closed as fixed.

[ck (Carlo Kok)]

I fixed it; or at least it looks like it (your testcase). What happened is that the “stackbase” pointer was wrong. The GC did work, and it also automatically worked but it ran in a JS timer, so there was nothing on the (wasm) stack, so it never failed on that. If you explicitly called the GC it scanned the stack but the stack base pointer was wrong so it didn’t “see” the items on the current wasm call stack. You can either wait till the friday build or grab latest IslandRTL.

[asiwecki (Adam Siwecki)]

Thank you Carlo. Sorry for not responding for a coupe of days, I’m on vacation right now. I’ll test the fix as soon as I get back. Hopefully this will end our memory problems.

[RemObjectsSoftware (RemObjects)]

bugs://E25502 was closed as unable to reproduce.

[asiwecki (Adam Siwecki)]

@ck, I’ve run a couple of tests on 11.0.0.2695 and GC clearly works now but there are 3 problems:

1. It seems that GC collects automatically only when control is fully returned to JS and no WASM code is pending execution (making a JS callback in WASM doesn’t trigger GC). This makes it necessary to call GC manually when an operation is memory consuming and might hit the limit before WASM code finishes.
2. The performance is terrible, each test I run takes few times longer compared to previous versions. If I call Collect manually then the whole operation takes longer, if I let GC do its job when the control is returned to JS then the operation freezes at the end.
3. GC still clears more than it should. Since yesterday I’m trying to distill the problematic code path but it seems to be much deeper than before. The trace I’m following is related to an object handle inside a record. I’ll post a test case if I succeed.

[RemObjectsSoftware (RemObjects)]

Logged as bugs://E25556.

[ck (Carlo Kok)]

@asiwecki

GC still clears more than it should. Since yesterday I’m trying to distill the problematic code path but it seems to be much deeper than before. The trace I’m following is related to an object handle inside a record. I’ll post a test case if I succeed.

I’ll take a look at your points; for (2) it seems the list keeps growing, however could it be that (3) only occurs if you manually do GC.Collect?

[asiwecki (Adam Siwecki)]

@ck

could it be that (3) only occurs if you manually do GC.Collect?

There’s no way to test that for automatic GC collection because it’s triggered after the operation has finished. If I frequently call Collect while the operation is running I get null reference on objects that should still exist.

[ck (Carlo Kok)]

Want to give a headsup: So I’m not very happy with the “SimpleGC” (as we use on WASM now) and today I’ve been working hard on getting BoehmGC, as we use on Windows/Linux/OSX with Island. We’re still testing this but it’s looking good so far. I expect this to be a lot faster both in cleanup and in lack of reference counting.

I think, and hope that this solves all issues you have with the current GC.

[asiwecki (Adam Siwecki)]

Great news! I was just following up on this (more problems) but since SimpleGC is gone I won’t bother you. I’m waiting to test BoehmGC then. Thanks Carlo!

[asiwecki (Adam Siwecki)]

@ck, I’m testing 11.0.0.2697 since this morning and, unfortunately, I can barely run anything after the switch to BoehmGC. Here’s a simple test case, depending on which line you uncomment you get different exception.
wasm_boehmgc.zip (4.8 KB)

[Theo69 (Theo)]

I had an issue in InitGC, but that was gone after I deleted the OBJ folder and a rebuild.