Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Oilpan can theoretically be used as a library as well - see: https://v8.dev/blog/oilpan-library https://v8.dev/blog/tags/cppgc https://chromium.googlesource.com/v8/v8.git/+/HEAD/include/c...

Due to the nature of web engine workloads migrating objects to being GC'd isn't performance negative (as most people would expect). With care it can often end up performance positive.

There are a few tricks that Oilpan can apply. Concurrent tracing helps a lot (e.g. instead of incrementing/decrementing refs, you can trace on a different thread), in addition when destructing objects, the destructors typically become trivial meaning the object can just be dropped from memory. Both these free up main thread time. (The tradeoff with concurrent tracing is that you need atomic barriers when assigning pointers which needs care).

This is on top of the safey improvements you gain from being GC'd vs. smart pointers, etc.

One major tradeoff that UAF bugs become more difficult to fix, as you are just accessing objects which "should" be dead.



> One major tradeoff that UAF bugs become more difficult to fix, as you are just accessing objects which "should" be dead.

Are you referring to access through a raw pointer after ownership has been dropped and then garbage collection is non deterministic?


> Are you referring to access through a raw pointer after ownership has been dropped and then garbage collection is non deterministic?

No - basically objects sometimes have some state of when they are "destroyed", e.g. an Element detached from the DOM tree[1]. Other parts of the codebase might have references to these objects, and previously accessing them after they destroyed would be a UAF. Now its just a bug. This is good! Its not a security bug anymore! However much harder to determine what is happening as it isn't a hard crash.

[1] This isn't a real case, just an example.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: