[wasm] Notify jiterpreter when a method is freed by kg · Pull Request #89980 · dotnet/runtime

kg · 2023-08-03T22:47:39Z

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

ghost · 2023-08-03T22:47:48Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information. It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	-
Labels:	`NO-MERGE`, `arch-wasm`
Milestone:	-

kg · 2023-08-08T03:45:16Z

Updated so that the interp_entry and jit_call queues are now stored in the native heap in thread-local lists, and there's a central list tracking all of those lists. So any time a method is freed we can acquire a lock and go through all the queues and ensure the freed method isn't in them, synchronously. This avoids the need to somehow push a callback to all of our threads. (We do still need to clean up their state, but it's less important)

Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

ghost · 2023-08-15T02:52:55Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	kg
Labels:	`arch-wasm`, `area-Codegen-Interpreter-mono`
Milestone:	-

lambdageek

LGTM.

Two areas to call out (but I'm not sure if there's anything to be done about it):

the EMSCRIPTEN_KEEPALIVE functions are pretty fragile since they don't have GC state transitions and use OS (not coop) mutexes. It might be enough to just comment that adding work inside those locks needs to be done carefully.
I don't know if the jiterp would ever run outside of WASM, but we do have mono helpers for the TLS keys and atomic increments.

lewing · 2023-08-18T16:34:01Z

Should we take this in main? Should it still be considered for 8?

kg · 2023-08-18T17:25:20Z

Should we take this in main? Should it still be considered for 8?

We would have to backport both this and multithreading support to take this in 8.

kg · 2023-08-03T22:47:39Z

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

ghost · 2023-08-03T22:47:48Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information. It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	-
Labels:	`NO-MERGE`, `arch-wasm`
Milestone:	-

kg · 2023-08-08T03:45:16Z

Updated so that the interp_entry and jit_call queues are now stored in the native heap in thread-local lists, and there's a central list tracking all of those lists. So any time a method is freed we can acquire a lock and go through all the queues and ensure the freed method isn't in them, synchronously. This avoids the need to somehow push a callback to all of our threads. (We do still need to clean up their state, but it's less important)

Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

ghost · 2023-08-15T02:52:55Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	kg
Labels:	`arch-wasm`, `area-Codegen-Interpreter-mono`
Milestone:	-

lambdageek

LGTM.

Two areas to call out (but I'm not sure if there's anything to be done about it):

the EMSCRIPTEN_KEEPALIVE functions are pretty fragile since they don't have GC state transitions and use OS (not coop) mutexes. It might be enough to just comment that adding work inside those locks needs to be done carefully.
I don't know if the jiterp would ever run outside of WASM, but we do have mono helpers for the TLS keys and atomic increments.

lewing · 2023-08-18T16:34:01Z

Should we take this in main? Should it still be considered for 8?

kg · 2023-08-18T17:25:20Z

Should we take this in main? Should it still be considered for 8?

We would have to backport both this and multithreading support to take this in 8.

kg · 2023-08-03T22:47:39Z

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

ghost · 2023-08-03T22:47:48Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information. It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	-
Labels:	`NO-MERGE`, `arch-wasm`
Milestone:	-

kg · 2023-08-08T03:45:16Z

Updated so that the interp_entry and jit_call queues are now stored in the native heap in thread-local lists, and there's a central list tracking all of those lists. So any time a method is freed we can acquire a lock and go through all the queues and ensure the freed method isn't in them, synchronously. This avoids the need to somehow push a callback to all of our threads. (We do still need to clean up their state, but it's less important)

Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

ghost · 2023-08-15T02:52:55Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	kg
Labels:	`arch-wasm`, `area-Codegen-Interpreter-mono`
Milestone:	-

lambdageek

LGTM.

Two areas to call out (but I'm not sure if there's anything to be done about it):

the EMSCRIPTEN_KEEPALIVE functions are pretty fragile since they don't have GC state transitions and use OS (not coop) mutexes. It might be enough to just comment that adding work inside those locks needs to be done carefully.
I don't know if the jiterp would ever run outside of WASM, but we do have mono helpers for the TLS keys and atomic increments.

lewing · 2023-08-18T16:34:01Z

Should we take this in main? Should it still be considered for 8?

kg · 2023-08-18T17:25:20Z

Should we take this in main? Should it still be considered for 8?

We would have to backport both this and multithreading support to take this in 8.

kg · 2023-08-03T22:47:39Z

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

ghost · 2023-08-03T22:47:48Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information. It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	-
Labels:	`NO-MERGE`, `arch-wasm`
Milestone:	-

kg · 2023-08-08T03:45:16Z

Updated so that the interp_entry and jit_call queues are now stored in the native heap in thread-local lists, and there's a central list tracking all of those lists. So any time a method is freed we can acquire a lock and go through all the queues and ensure the freed method isn't in them, synchronously. This avoids the need to somehow push a callback to all of our threads. (We do still need to clean up their state, but it's less important)

Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

ghost · 2023-08-15T02:52:55Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	kg
Labels:	`arch-wasm`, `area-Codegen-Interpreter-mono`
Milestone:	-

lambdageek

LGTM.

Two areas to call out (but I'm not sure if there's anything to be done about it):

the EMSCRIPTEN_KEEPALIVE functions are pretty fragile since they don't have GC state transitions and use OS (not coop) mutexes. It might be enough to just comment that adding work inside those locks needs to be done carefully.
I don't know if the jiterp would ever run outside of WASM, but we do have mono helpers for the TLS keys and atomic increments.

lewing · 2023-08-18T16:34:01Z

Should we take this in main? Should it still be considered for 8?

kg · 2023-08-18T17:25:20Z

Should we take this in main? Should it still be considered for 8?

We would have to backport both this and multithreading support to take this in 8.

kg · 2023-08-03T22:47:39Z

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

ghost · 2023-08-03T22:47:48Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information. It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	-
Labels:	`NO-MERGE`, `arch-wasm`
Milestone:	-

kg · 2023-08-08T03:45:16Z

Updated so that the interp_entry and jit_call queues are now stored in the native heap in thread-local lists, and there's a central list tracking all of those lists. So any time a method is freed we can acquire a lock and go through all the queues and ensure the freed method isn't in them, synchronously. This avoids the need to somehow push a callback to all of our threads. (We do still need to clean up their state, but it's less important)

Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

ghost · 2023-08-15T02:52:55Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	kg
Labels:	`arch-wasm`, `area-Codegen-Interpreter-mono`
Milestone:	-

lambdageek

LGTM.

Two areas to call out (but I'm not sure if there's anything to be done about it):

the EMSCRIPTEN_KEEPALIVE functions are pretty fragile since they don't have GC state transitions and use OS (not coop) mutexes. It might be enough to just comment that adding work inside those locks needs to be done carefully.
I don't know if the jiterp would ever run outside of WASM, but we do have mono helpers for the TLS keys and atomic increments.

lewing · 2023-08-18T16:34:01Z

Should we take this in main? Should it still be considered for 8?

kg · 2023-08-18T17:25:20Z

Should we take this in main? Should it still be considered for 8?

We would have to backport both this and multithreading support to take this in 8.

kg · 2023-08-03T22:47:39Z

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

ghost · 2023-08-03T22:47:48Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information. It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	-
Labels:	`NO-MERGE`, `arch-wasm`
Milestone:	-

kg · 2023-08-08T03:45:16Z

Updated so that the interp_entry and jit_call queues are now stored in the native heap in thread-local lists, and there's a central list tracking all of those lists. So any time a method is freed we can acquire a lock and go through all the queues and ensure the freed method isn't in them, synchronously. This avoids the need to somehow push a callback to all of our threads. (We do still need to clean up their state, but it's less important)

Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

ghost · 2023-08-15T02:52:55Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	kg
Labels:	`arch-wasm`, `area-Codegen-Interpreter-mono`
Milestone:	-

lambdageek

LGTM.

Two areas to call out (but I'm not sure if there's anything to be done about it):

the EMSCRIPTEN_KEEPALIVE functions are pretty fragile since they don't have GC state transitions and use OS (not coop) mutexes. It might be enough to just comment that adding work inside those locks needs to be done carefully.
I don't know if the jiterp would ever run outside of WASM, but we do have mono helpers for the TLS keys and atomic increments.

lewing · 2023-08-18T16:34:01Z

Should we take this in main? Should it still be considered for 8?

kg · 2023-08-18T17:25:20Z

Should we take this in main? Should it still be considered for 8?

We would have to backport both this and multithreading support to take this in 8.

kg · 2023-08-03T22:47:39Z

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

ghost · 2023-08-03T22:47:48Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information. It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	-
Labels:	`NO-MERGE`, `arch-wasm`
Milestone:	-

kg · 2023-08-08T03:45:16Z

Updated so that the interp_entry and jit_call queues are now stored in the native heap in thread-local lists, and there's a central list tracking all of those lists. So any time a method is freed we can acquire a lock and go through all the queues and ensure the freed method isn't in them, synchronously. This avoids the need to somehow push a callback to all of our threads. (We do still need to clean up their state, but it's less important)

Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

ghost · 2023-08-15T02:52:55Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	kg
Labels:	`arch-wasm`, `area-Codegen-Interpreter-mono`
Milestone:	-

lambdageek

LGTM.

Two areas to call out (but I'm not sure if there's anything to be done about it):

the EMSCRIPTEN_KEEPALIVE functions are pretty fragile since they don't have GC state transitions and use OS (not coop) mutexes. It might be enough to just comment that adding work inside those locks needs to be done carefully.
I don't know if the jiterp would ever run outside of WASM, but we do have mono helpers for the TLS keys and atomic increments.

lewing · 2023-08-18T16:34:01Z

Should we take this in main? Should it still be considered for 8?

kg · 2023-08-18T17:25:20Z

Should we take this in main? Should it still be considered for 8?

We would have to backport both this and multithreading support to take this in 8.

kg · 2023-08-03T22:47:39Z

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

ghost · 2023-08-03T22:47:48Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information. It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	-
Labels:	`NO-MERGE`, `arch-wasm`
Milestone:	-

kg · 2023-08-08T03:45:16Z

Updated so that the interp_entry and jit_call queues are now stored in the native heap in thread-local lists, and there's a central list tracking all of those lists. So any time a method is freed we can acquire a lock and go through all the queues and ensure the freed method isn't in them, synchronously. This avoids the need to somehow push a callback to all of our threads. (We do still need to clean up their state, but it's less important)

Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

ghost · 2023-08-15T02:52:55Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

Issue Details

In some cases a MonoMethod and its associated InterpMethod can be freed at runtime. The jiterpreter currently knows nothing about this, and in very rare circumstances it's possible that something new would get allocated at the same address. Very bad things would probably happen if so.

This PR updates the jiterpreter to clear freed methods from its JIT queues and discards some state so that if a new object is allocated at the same address, it won't inherit old information.

It also changes some tables that previously used raw memory addresses to use assigned indices instead, which should help with the 'we freed something and then put something new there' problem.

It is very hard to manually reproduce the scenario that I think caused #89670 but I was at least able to verify during testing that methods can be freed while the jit queue is not empty, so hopefully this will fix that.

At some point we probably also want to update the jiterpreter so that if a method is freed, we remove the function pointer so that the browser is able to potentially release the memory used by the compiled traces inside of it. But that's a big undertaking thanks to threads, so it's not in this PR.

Depends on #88279

Author:	kg
Assignees:	kg
Labels:	`arch-wasm`, `area-Codegen-Interpreter-mono`
Milestone:	-

lambdageek

LGTM.

Two areas to call out (but I'm not sure if there's anything to be done about it):

the EMSCRIPTEN_KEEPALIVE functions are pretty fragile since they don't have GC state transitions and use OS (not coop) mutexes. It might be enough to just comment that adding work inside those locks needs to be done carefully.
I don't know if the jiterp would ever run outside of WASM, but we do have mono helpers for the TLS keys and atomic increments.

lewing · 2023-08-18T16:34:01Z

Should we take this in main? Should it still be considered for 8?

kg · 2023-08-18T17:25:20Z

Should we take this in main? Should it still be considered for 8?

We would have to backport both this and multithreading support to take this in 8.

kg added NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) arch-wasm WebAssembly architecture labels Aug 3, 2023

ghost assigned kg Aug 3, 2023

ghost added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Aug 3, 2023

build-analysisBot mentioned this pull request Aug 4, 2023
Insufficient memory of docker containers on CI dotnet/dnceng#450
Closed
3 tasks

kg added 2 commits August 14, 2023 18:33

[MERGE DAMAGED]
c769276
Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

Repair merge damage
7c4cb62

kg force-pushed the jiterp-method-free branch from 9728807 to 7c4cb62Compare August 15, 2023 02:03

kg added 3 commits August 14, 2023 19:41

Cleanup free_method_data
3945960

Fix lock held open
703bb09

Repair merge damage
c32df64

kg marked this pull request as ready for review August 15, 2023 02:52

kg requested review from BrzVlad, kotlarmilos, lewing, pavelsavara and vargaz as code owners August 15, 2023 02:52

kg added area-Codegen-Interpreter-mono and removed NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Aug 15, 2023

kg requested a review from lambdageek August 15, 2023 02:53

kg added 2 commits August 14, 2023 19:55

Fix race in trace_info_alloc
d5579e6

Annotate races for later cleanup
798aab0

build-analysisBot mentioned this pull request Aug 15, 2023
Tracking issue for "WORKLOAD TIMED OUT" #90309
Closed

lambdageek approved these changes Aug 15, 2023
View reviewed changes

Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated

Address PR feedback
2464dd3

kg requested a review from lambdageek August 16, 2023 02:48

lambdageek approved these changes Aug 18, 2023
View reviewed changes

kg merged commit 1e40c04 into dotnet:mainAug 21, 2023

ghost locked as resolved and limited conversation to collaborators Sep 20, 2023

kg added NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) arch-wasm WebAssembly architecture labels Aug 3, 2023

ghost assigned kg Aug 3, 2023

ghost added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Aug 3, 2023

build-analysisBot mentioned this pull request Aug 4, 2023
Insufficient memory of docker containers on CI dotnet/dnceng#450
Closed
3 tasks

kg added 2 commits August 14, 2023 18:33

[MERGE DAMAGED]
c769276
Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

Repair merge damage
7c4cb62

kg force-pushed the jiterp-method-free branch from 9728807 to 7c4cb62Compare August 15, 2023 02:03

kg added 3 commits August 14, 2023 19:41

Cleanup free_method_data
3945960

Fix lock held open
703bb09

Repair merge damage
c32df64

kg marked this pull request as ready for review August 15, 2023 02:52

kg requested review from BrzVlad, kotlarmilos, lewing, pavelsavara and vargaz as code owners August 15, 2023 02:52

kg added area-Codegen-Interpreter-mono and removed NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Aug 15, 2023

kg requested a review from lambdageek August 15, 2023 02:53

kg added 2 commits August 14, 2023 19:55

Fix race in trace_info_alloc
d5579e6

Annotate races for later cleanup
798aab0

build-analysisBot mentioned this pull request Aug 15, 2023
Tracking issue for "WORKLOAD TIMED OUT" #90309
Closed

lambdageek approved these changes Aug 15, 2023
View reviewed changes

Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated

Address PR feedback
2464dd3

kg requested a review from lambdageek August 16, 2023 02:48

lambdageek approved these changes Aug 18, 2023
View reviewed changes

kg merged commit 1e40c04 into dotnet:mainAug 21, 2023

ghost locked as resolved and limited conversation to collaborators Sep 20, 2023

kg added NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) arch-wasm WebAssembly architecture labels Aug 3, 2023

ghost assigned kg Aug 3, 2023

ghost added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Aug 3, 2023

build-analysisBot mentioned this pull request Aug 4, 2023
Insufficient memory of docker containers on CI dotnet/dnceng#450
Closed
3 tasks

kg added 2 commits August 14, 2023 18:33

[MERGE DAMAGED]
c769276
Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

Repair merge damage
7c4cb62

kg force-pushed the jiterp-method-free branch from 9728807 to 7c4cb62Compare August 15, 2023 02:03

kg added 3 commits August 14, 2023 19:41

Cleanup free_method_data
3945960

Fix lock held open
703bb09

Repair merge damage
c32df64

kg marked this pull request as ready for review August 15, 2023 02:52

kg requested review from BrzVlad, kotlarmilos, lewing, pavelsavara and vargaz as code owners August 15, 2023 02:52

kg added area-Codegen-Interpreter-mono and removed NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Aug 15, 2023

kg requested a review from lambdageek August 15, 2023 02:53

kg added 2 commits August 14, 2023 19:55

Fix race in trace_info_alloc
d5579e6

Annotate races for later cleanup
798aab0

build-analysisBot mentioned this pull request Aug 15, 2023
Tracking issue for "WORKLOAD TIMED OUT" #90309
Closed

lambdageek approved these changes Aug 15, 2023
View reviewed changes

Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated

Address PR feedback
2464dd3

kg requested a review from lambdageek August 16, 2023 02:48

lambdageek approved these changes Aug 18, 2023
View reviewed changes

kg merged commit 1e40c04 into dotnet:mainAug 21, 2023

ghost locked as resolved and limited conversation to collaborators Sep 20, 2023

kg added NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) arch-wasm WebAssembly architecture labels Aug 3, 2023

ghost assigned kg Aug 3, 2023

ghost added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Aug 3, 2023

build-analysisBot mentioned this pull request Aug 4, 2023
Insufficient memory of docker containers on CI dotnet/dnceng#450
Closed
3 tasks

kg added 2 commits August 14, 2023 18:33

[MERGE DAMAGED]
c769276
Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

Repair merge damage
7c4cb62

kg force-pushed the jiterp-method-free branch from 9728807 to 7c4cb62Compare August 15, 2023 02:03

kg added 3 commits August 14, 2023 19:41

Cleanup free_method_data
3945960

Fix lock held open
703bb09

Repair merge damage
c32df64

kg marked this pull request as ready for review August 15, 2023 02:52

kg requested review from BrzVlad, kotlarmilos, lewing, pavelsavara and vargaz as code owners August 15, 2023 02:52

kg added area-Codegen-Interpreter-mono and removed NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Aug 15, 2023

kg requested a review from lambdageek August 15, 2023 02:53

kg added 2 commits August 14, 2023 19:55

Fix race in trace_info_alloc
d5579e6

Annotate races for later cleanup
798aab0

build-analysisBot mentioned this pull request Aug 15, 2023
Tracking issue for "WORKLOAD TIMED OUT" #90309
Closed

lambdageek approved these changes Aug 15, 2023
View reviewed changes

Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated

Address PR feedback
2464dd3

kg requested a review from lambdageek August 16, 2023 02:48

lambdageek approved these changes Aug 18, 2023
View reviewed changes

kg merged commit 1e40c04 into dotnet:mainAug 21, 2023

ghost locked as resolved and limited conversation to collaborators Sep 20, 2023

kg added NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) arch-wasm WebAssembly architecture labels Aug 3, 2023

ghost assigned kg Aug 3, 2023

ghost added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Aug 3, 2023

build-analysisBot mentioned this pull request Aug 4, 2023
Insufficient memory of docker containers on CI dotnet/dnceng#450
Closed
3 tasks

kg added 2 commits August 14, 2023 18:33

[MERGE DAMAGED]
c769276
Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

Repair merge damage
7c4cb62

kg force-pushed the jiterp-method-free branch from 9728807 to 7c4cb62Compare August 15, 2023 02:03

kg added 3 commits August 14, 2023 19:41

Cleanup free_method_data
3945960

Fix lock held open
703bb09

Repair merge damage
c32df64

kg marked this pull request as ready for review August 15, 2023 02:52

kg requested review from BrzVlad, kotlarmilos, lewing, pavelsavara and vargaz as code owners August 15, 2023 02:52

kg added area-Codegen-Interpreter-mono and removed NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Aug 15, 2023

kg requested a review from lambdageek August 15, 2023 02:53

kg added 2 commits August 14, 2023 19:55

Fix race in trace_info_alloc
d5579e6

Annotate races for later cleanup
798aab0

build-analysisBot mentioned this pull request Aug 15, 2023
Tracking issue for "WORKLOAD TIMED OUT" #90309
Closed

lambdageek approved these changes Aug 15, 2023
View reviewed changes

Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated

Address PR feedback
2464dd3

kg requested a review from lambdageek August 16, 2023 02:48

lambdageek approved these changes Aug 18, 2023
View reviewed changes

kg merged commit 1e40c04 into dotnet:mainAug 21, 2023

ghost locked as resolved and limited conversation to collaborators Sep 20, 2023

kg added NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) arch-wasm WebAssembly architecture labels Aug 3, 2023

ghost assigned kg Aug 3, 2023

ghost added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Aug 3, 2023

build-analysisBot mentioned this pull request Aug 4, 2023
Insufficient memory of docker containers on CI dotnet/dnceng#450
Closed
3 tasks

kg added 2 commits August 14, 2023 18:33

[MERGE DAMAGED]
c769276
Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

Repair merge damage
7c4cb62

kg force-pushed the jiterp-method-free branch from 9728807 to 7c4cb62Compare August 15, 2023 02:03

kg added 3 commits August 14, 2023 19:41

Cleanup free_method_data
3945960

Fix lock held open
703bb09

Repair merge damage
c32df64

kg marked this pull request as ready for review August 15, 2023 02:52

kg requested review from BrzVlad, kotlarmilos, lewing, pavelsavara and vargaz as code owners August 15, 2023 02:52

kg added area-Codegen-Interpreter-mono and removed NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Aug 15, 2023

kg requested a review from lambdageek August 15, 2023 02:53

kg added 2 commits August 14, 2023 19:55

Fix race in trace_info_alloc
d5579e6

Annotate races for later cleanup
798aab0

build-analysisBot mentioned this pull request Aug 15, 2023
Tracking issue for "WORKLOAD TIMED OUT" #90309
Closed

lambdageek approved these changes Aug 15, 2023
View reviewed changes

Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated

Address PR feedback
2464dd3

kg requested a review from lambdageek August 16, 2023 02:48

lambdageek approved these changes Aug 18, 2023
View reviewed changes

kg merged commit 1e40c04 into dotnet:mainAug 21, 2023

ghost locked as resolved and limited conversation to collaborators Sep 20, 2023

kg added NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) arch-wasm WebAssembly architecture labels Aug 3, 2023

ghost assigned kg Aug 3, 2023

ghost added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Aug 3, 2023

build-analysisBot mentioned this pull request Aug 4, 2023
Insufficient memory of docker containers on CI dotnet/dnceng#450
Closed
3 tasks

kg added 2 commits August 14, 2023 18:33

[MERGE DAMAGED]
c769276
Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

Repair merge damage
7c4cb62

kg force-pushed the jiterp-method-free branch from 9728807 to 7c4cb62Compare August 15, 2023 02:03

kg added 3 commits August 14, 2023 19:41

Cleanup free_method_data
3945960

Fix lock held open
703bb09

Repair merge damage
c32df64

kg marked this pull request as ready for review August 15, 2023 02:52

kg requested review from BrzVlad, kotlarmilos, lewing, pavelsavara and vargaz as code owners August 15, 2023 02:52

kg added area-Codegen-Interpreter-mono and removed NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Aug 15, 2023

kg requested a review from lambdageek August 15, 2023 02:53

kg added 2 commits August 14, 2023 19:55

Fix race in trace_info_alloc
d5579e6

Annotate races for later cleanup
798aab0

build-analysisBot mentioned this pull request Aug 15, 2023
Tracking issue for "WORKLOAD TIMED OUT" #90309
Closed

lambdageek approved these changes Aug 15, 2023
View reviewed changes

Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated

Address PR feedback
2464dd3

kg requested a review from lambdageek August 16, 2023 02:48

lambdageek approved these changes Aug 18, 2023
View reviewed changes

kg merged commit 1e40c04 into dotnet:mainAug 21, 2023

ghost locked as resolved and limited conversation to collaborators Sep 20, 2023

kg added NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) arch-wasm WebAssembly architecture labels Aug 3, 2023

ghost assigned kg Aug 3, 2023

ghost added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Aug 3, 2023

build-analysisBot mentioned this pull request Aug 4, 2023
Insufficient memory of docker containers on CI dotnet/dnceng#450
Closed
3 tasks

kg added 2 commits August 14, 2023 18:33

[MERGE DAMAGED]
c769276
Notify jiterpreter when a method is freed and ensure it isn't in the jit queues Fix infosByMethod not being populated Checkpoint: Migrate jiterpreter jit queues to C thread-local memory Use tlqueue for interp_entry as well

Repair merge damage
7c4cb62

kg force-pushed the jiterp-method-free branch from 9728807 to 7c4cb62Compare August 15, 2023 02:03

kg added 3 commits August 14, 2023 19:41

Cleanup free_method_data
3945960

Fix lock held open
703bb09

Repair merge damage
c32df64

kg marked this pull request as ready for review August 15, 2023 02:52

kg requested review from BrzVlad, kotlarmilos, lewing, pavelsavara and vargaz as code owners August 15, 2023 02:52

kg added area-Codegen-Interpreter-mono and removed NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Aug 15, 2023

kg requested a review from lambdageek August 15, 2023 02:53

kg added 2 commits August 14, 2023 19:55

Fix race in trace_info_alloc
d5579e6

Annotate races for later cleanup
798aab0

build-analysisBot mentioned this pull request Aug 15, 2023
Tracking issue for "WORKLOAD TIMED OUT" #90309
Closed

lambdageek approved these changes Aug 15, 2023
View reviewed changes

Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated
Comment threadsrc/mono/mono/mini/interp/jiterpreter.c Outdated

Address PR feedback
2464dd3

kg requested a review from lambdageek August 16, 2023 02:48

lambdageek approved these changes Aug 18, 2023
View reviewed changes

kg merged commit 1e40c04 into dotnet:mainAug 21, 2023

ghost locked as resolved and limited conversation to collaborators Sep 20, 2023

Uh oh!

Conversation

kg commented Aug 3, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Aug 3, 2023

Uh oh!

kg commented Aug 8, 2023

Uh oh!

ghost commented Aug 15, 2023

Uh oh!

lambdageek left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lewing commented Aug 18, 2023

Uh oh!

kg commented Aug 18, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

kg commented Aug 3, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Aug 3, 2023

Uh oh!

kg commented Aug 8, 2023

Uh oh!

ghost commented Aug 15, 2023

Uh oh!

lambdageek left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lewing commented Aug 18, 2023

Uh oh!

kg commented Aug 18, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

kg commented Aug 3, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Aug 3, 2023

Uh oh!

kg commented Aug 8, 2023

Uh oh!

ghost commented Aug 15, 2023

Uh oh!

lambdageek left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lewing commented Aug 18, 2023

Uh oh!

kg commented Aug 3, 2023•
edited
Loading

kg commented Aug 3, 2023•
edited
Loading

kg commented Aug 3, 2023•
edited
Loading

kg commented Aug 3, 2023•
edited
Loading

kg commented Aug 3, 2023•
edited
Loading