😿 Job mac-m1_mini_2020-perf-pgo/blink_perf.layout failed.
See results at: https://pinpoint-dot-chromeperf.appspot.com/job/137d57ef710000
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hi Kurt. I'm afraid the GC related changes in this CL are unsafe. There would be more issues than just concurrent allocations, and there is no easy fix for them (e.g. the concurrent accesses are also unsafe, as well as any raw pointers you'd hold on stack). Please avoid making changes to the GC.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
📍 Job mac-m1_mini_2020-perf-pgo/speedometer3 complete.
See results at: https://pinpoint-dot-chromeperf.appspot.com/job/12b2de83710000
📍 Job mac-m1_mini_2020-perf-pgo/blink_perf.layout complete.
See results at: https://pinpoint-dot-chromeperf.appspot.com/job/1195bac4f10000
Hi Kurt. I'm afraid the GC related changes in this CL are unsafe. There would be more issues than just concurrent allocations, and there is no easy fix for them (e.g. the concurrent accesses are also unsafe, as well as any raw pointers you'd hold on stack). Please avoid making changes to the GC.
That's what I figured, this is just an experiment to see if it makes any difference performance-wise. Right now, it's looking like the answer is no, as it loses the caching the current implementation achieves. I don't plan on landing this.
Kurt Catti-SchmidtHi Kurt. I'm afraid the GC related changes in this CL are unsafe. There would be more issues than just concurrent allocations, and there is no easy fix for them (e.g. the concurrent accesses are also unsafe, as well as any raw pointers you'd hold on stack). Please avoid making changes to the GC.
That's what I figured, this is just an experiment to see if it makes any difference performance-wise. Right now, it's looking like the answer is no, as it loses the caching the current implementation achieves. I don't plan on landing this.
Thanks. Just FYI: Even if this experiment improved performance, making something like GC-safe would afaik be a multiple-quarter project requiring changes to the GC itself. I don't think this can be resolved solely on the blink side.
Kurt Catti-SchmidtHi Kurt. I'm afraid the GC related changes in this CL are unsafe. There would be more issues than just concurrent allocations, and there is no easy fix for them (e.g. the concurrent accesses are also unsafe, as well as any raw pointers you'd hold on stack). Please avoid making changes to the GC.
Omer KatzThat's what I figured, this is just an experiment to see if it makes any difference performance-wise. Right now, it's looking like the answer is no, as it loses the caching the current implementation achieves. I don't plan on landing this.
Thanks. Just FYI: Even if this experiment improved performance, making something like GC-safe would afaik be a multiple-quarter project requiring changes to the GC itself. I don't think this can be resolved solely on the blink side.
Kurt Catti-Schmidt abandoned this change.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |