Add link to Redex blog article #1
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@facebook-github-bot import |
1 similar comment
|
@facebook-github-bot import |
|
Thanks for importing. If you are an FB employee go to Phabricator to review. |
ghost
closed this
in
facebook-github-bot
pushed a commit
that referenced
this pull request
Oct 24, 2017
Summary: This analysis infers the access paths (in terms of sequences of getters) into an immutable data structure passed as an argument to a method. For instance, the analysis can tell that at a certain point in the code, register `v_n` points to the subcomponent `p1.getA().getB(C).getC()` of the structure contained in parameter #1. Reviewed By: justinjhendrick Differential Revision: D6096746 fbshipit-source-id: 9f67922d124acb8465722ed4b6e77935962cc23d
facebook-github-bot
pushed a commit
that referenced
this pull request
Mar 6, 2018
Summary: the OatDexFileRecord appears to be v131 only but we are still attempting to write it at 8.0 v124 on an mac this results in a segfault when we attempt to write: * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ffeefc00000) ... frame #3: 0x0000000100000851 oatmeal`FileHandle::fwrite_impl(this=0x00007ffeefbfcfb8, p=0x00007ffeefbfd071, size=1, count=2811670808) at OatmealUtil.cpp:16 ... on the device we get a message in stderr with native/redex/tools/oatmeal/OatmealUtil.cpp:60 CHECK(fh.fwrite(buf.ptr, sizeof(char), buf.len) == buf.len) failed. but the binary doesnt seem to crash even though there is an assert there. Reviewed By: maxmg22 Differential Revision: D7158457 fbshipit-source-id: e4f52cb4184ec519f30a4f11948e4633ad152c9b
diegoflassa
pushed a commit
to diegoflassa/redex
that referenced
this pull request
Apr 16, 2018
Summary: the OatDexFileRecord appears to be v131 only but we are still attempting to write it at 8.0 v124 on an mac this results in a segfault when we attempt to write: * thread facebook#1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ffeefc00000) ... frame facebook#3: 0x0000000100000851 oatmeal`FileHandle::fwrite_impl(this=0x00007ffeefbfcfb8, p=0x00007ffeefbfd071, size=1, count=2811670808) at OatmealUtil.cpp:16 ... on the device we get a message in stderr with native/redex/tools/oatmeal/OatmealUtil.cpp:60 CHECK(fh.fwrite(buf.ptr, sizeof(char), buf.len) == buf.len) failed. but the binary doesnt seem to crash even though there is an assert there. Reviewed By: maxmg22 Differential Revision: D7158457 fbshipit-source-id: e4f52cb4184ec519f30a4f11948e4633ad152c9b
diegoflassa
pushed a commit
to diegoflassa/redex
that referenced
this pull request
Apr 19, 2018
Summary: the OatDexFileRecord appears to be v131 only but we are still attempting to write it at 8.0 v124 on an mac this results in a segfault when we attempt to write: * thread facebook#1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ffeefc00000) ... frame facebook#3: 0x0000000100000851 oatmeal`FileHandle::fwrite_impl(this=0x00007ffeefbfcfb8, p=0x00007ffeefbfd071, size=1, count=2811670808) at OatmealUtil.cpp:16 ... on the device we get a message in stderr with native/redex/tools/oatmeal/OatmealUtil.cpp:60 CHECK(fh.fwrite(buf.ptr, sizeof(char), buf.len) == buf.len) failed. but the binary doesnt seem to crash even though there is an assert there. Reviewed By: maxmg22 Differential Revision: D7158457 fbshipit-source-id: e4f52cb4184ec519f30a4f11948e4633ad152c9b
facebook-github-bot
pushed a commit
that referenced
this pull request
Oct 15, 2019
Summary: Report: fbandroid/native/redex/libresource/VectorImpl.cpp:507:22: runtime error: null pointer passed as argument 2, which is declared to never be null fbcode/third-party-buck/platform007/build/glibc/include/string.h:43:28: note: nonnull attribute specified here Stack trace: ``` #0 android::VectorImpl::_do_copy (this=<optimized out>, dest=0x7fffd140c818, from=0x0, num=0) at fbandroid/native/redex/libresource/VectorImpl.cpp:507 #1 android::VectorImpl::setCapacity (this=0x7fffffff5ac0, new_capacity=25420576) at fbandroid/native/redex/libresource/VectorImpl.cpp:341 #2 0x0000000001f34f4a in android::Vector<char>::setCapacity (this=<optimized out>, size=17592186039131) at buck-out/gen/fbandroid/native/redex/libresource#header-mode-symlink-tree-with-header-map,headers/utils/Vector.h:85 #3 android::Vector<char>::reserve (this=<optimized out>, n=17592186039131) at buck-out/gen/fbandroid/native/redex/libresource#header-mode-symlink-tree-with-header-map,headers/utils/Vector.h:196 #4 android::ResTable::serialize (this=0x7fffffff66b0, cVec=..., resTableIndex=<optimized out>) at fbandroid/native/redex/libresource/ResourceTypes.cpp:4006 #5 0x0000000001e049eb in ResourcesArscFile::serialize (this=0x7fffffff66b0) at fbandroid/native/redex/libredex/RedexResources.cpp:1262 #6 0x00000000014ad94d in OptimizeResourcesPass::run_pass (this=0x24d25e0 <_ZL6s_pass>, stores=..., conf=..., mgr=...) at fbandroid/native/redex/facebook/opt/optimize_resources/OptimizeResources.cpp:630 #7 0x0000000001c6b2a9 in PassManager::run_passes (this=0x7fffffffb660, stores=..., conf=...) at fbandroid/native/redex/libredex/PassManager.cpp:258 #8 0x0000000000d2bb3a in main (argc=-25816, argv=0x7fffffffaf48) at fbandroid/native/redex/tools/redex-all/main.cpp:1122 ``` Reviewed By: int3 Differential Revision: D17889740 fbshipit-source-id: 360c1e7bd341a09f3537b9115cd2967d98b0c36c
facebook-github-bot
pushed a commit
that referenced
this pull request
Jan 5, 2021
Summary: I have been rebasing this each day since Thurs 12/10 and running locally to note which diffs would have been blocked: https://docs.google.com/spreadsheets/d/1qiFMrs149mL2q6qXeG0eAPfUd2rMLR5DDl1cCK5wbz8/edit?usp=sharing The main culprits include: 1) Using MobileConfig to gate things that happen to exist in the primary dex. 2) Bad code mods that are sprinkling Guava use cases everywhere. For #1, I think once existing packages like crash reporting get split up, this will become less of a problem over time. Or, once existing experiments in crash reporting infra are converted over to `FbColdStartExperiments` infra (a good thing to use from primary dex) new experiments would have good examples to copy. For #2, I've talked with the authors of the code mod and they're gonna use `//fbandroid/java/com/facebook/common/preconditions:preconditions` instead which isn't problematic. That said, the samples of the diffs that would valid validation is likely not going to be representative (end of year, people on PTO, etc). Though this is the best info I have right now. Also note, before landing I'll put out an Android FYI post and point people to the documentation. Here is the draft post: P155848149 Reviewed By: minjang Differential Revision: D25606766 fbshipit-source-id: e8089eb4159cbe9c85d05db9624797fbcafff789
facebook-github-bot
pushed a commit
that referenced
this pull request
Aug 23, 2022
Summary: This diff introduces two main changes: ### Update Graph interface Currently, `predecessors` and `successors` in Graph trait returns `&[Self::EdgeId]`, this would be fairly efficient for Graph implementations that can return a slice. But I realized that in many cases, the Graph implementations may only be able to return an iterator (e.g., using petgraph). To make the interface more flexible, I decide to update it. There are three options for the new return type: ``` // 1. A iterator trait object (lazily evaluated, dynamic dispatch). fn predecessors(&self, n: Self::NodeId) -> Box<dyn Iterator<Item = Self::EdgeId> + '_>; // 2. Vector (heap alloc). fn predecessors(&self, n: Self::NodeId) -> Vec<Self::EdgeId>; // 3. SmallVec is similar to LLVM SmallVector, which can hold data in stack if its size is smaller than S. fn predecessors(&self, n: Self::NodeId) -> SmallVec<[Self::EdgeId; S]>; ``` With some benchmarking using different numbers of successors (etc.,1, 2, 4, 6, 8, 10), it turns out that the option #1 and #2 has similar performance, while option #3 is always slightly better than the other two. So I decided to adopt it. This will introduce a new dependency to our library but it's small. (later I can put this kind of benchmarking code in a separate bench folder.) ### Add a new trait for getting successor nodes In WPO, we need an interface to query the successor nodes of a given node. Previously I used a closure for it (while the C++ version uses std::function). After discussing with yuxuanchen1997, we think it's better to make this a separate trait to achieve this, so we add `SuccessorNodes` (The type that implements Graph trait can also implement Fn trait, but it's not recommended in Rust). In most cases, the same type can implement both. But they can also be separate types. In addition, this diff adds a naive graph implementation for testing. In this diff we only use it to test the `get_succ_nodes` interface. Reviewed By: yuxuanchen1997 Differential Revision: D38846203 fbshipit-source-id: 7951b83a7df6817b3796c1a4e40d85e08b4c2c12
facebook-github-bot
pushed a commit
that referenced
this pull request
Aug 23, 2022
Summary: This diff introduces two main changes: ### Update Graph interface Currently, `predecessors` and `successors` in Graph trait returns `&[Self::EdgeId]`, this would be fairly efficient for Graph implementations that can return a slice. But I realized that in many cases, the Graph implementations may only be able to return an iterator (e.g., using petgraph). To make the interface more flexible, I decide to update it. There are three options for the new return type: ``` // 1. A iterator trait object (lazily evaluated, dynamic dispatch). fn predecessors(&self, n: Self::NodeId) -> Box<dyn Iterator<Item = Self::EdgeId> + '_>; // 2. Vector (heap alloc). fn predecessors(&self, n: Self::NodeId) -> Vec<Self::EdgeId>; // 3. SmallVec is similar to LLVM SmallVector, which can hold data in stack if its size is smaller than S. fn predecessors(&self, n: Self::NodeId) -> SmallVec<[Self::EdgeId; S]>; ``` With some benchmarking using different numbers of successors (etc.,1, 2, 4, 6, 8, 10), it turns out that the option #1 and #2 has similar performance, while option #3 is always slightly better than the other two. So I decided to adopt it. This will introduce a new dependency to our library but it's small. (later I can put this kind of benchmarking code in a separate bench folder.) ### Add a new trait for getting successor nodes In WPO, we need an interface to query the successor nodes of a given node. Previously I used a closure for it (while the C++ version uses std::function). After discussing with yuxuanchen1997, we think it's better to make this a separate trait to achieve this, so we add `SuccessorNodes` (The type that implements Graph trait can also implement Fn trait, but it's not recommended in Rust). In most cases, the same type can implement both. But they can also be separate types. In addition, this diff adds a naive graph implementation for testing. In this diff we only use it to test the `get_succ_nodes` interface. Reviewed By: yuxuanchen1997 Differential Revision: D38846203 fbshipit-source-id: 7951b83a7df6817b3796c1a4e40d85e08b4c2c12
facebook-github-bot
pushed a commit
that referenced
this pull request
Mar 11, 2024
…o redex-stable"" Summary: Original commit changeset: 6131d6892539 Original Phabricator Diff: D54648671 A summary of issues: 1) Build failures on mac: https://fb.workplace.com/groups/buck2users/permalink/3610890652500623/, https://fb.workplace.com/groups/redex.feedback/posts/7155760447827011 2) Sporadic failures observed at land time and continuous builds via our own reporting: https://fburl.com/scuba/android_redex_failures/k9d8kiqi 3) Perhaps because of #1, I cannot land a speculative change for #2, see D54707997 (https://www.internalfb.com/sandcastle/workflow/4228880050103139544/artifact/actionlog.4228880050147425325.stderr.1?selectedLines=37320-37320-98-98) Reviewed By: beicy Differential Revision: D54714856 fbshipit-source-id: 4690b26427ca9bef8a4cbabc313b44fd2445c4fa
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add a link to the Redex blog article on Facebook.