Bug: 28053584
Stop CloseGuarding for two reasons:
1) KernelID and FieldID objects are constructed in auto-generated
(RenderScript reflected) Java code. It would be impossible for a user to
explicitly call destroy() on them. Guarding them would leave a lot of
noisy warnings in logcat.
2) These KernelID and FieldID objects are not big compared to other
RenderScript objects, e.g. Allocations. They occupy almost no native
resources except for a native pointer. Leaving their destruction to Java
GC would be completely acceptable, since any delay in reclaiming them is
unlikely to cause memory pressure.
Test: CTS on x86_64 emulator
Change-Id: I587b5561a0b2bdbf0b2e95bf2995c20d5f5faf9d
Bug: 28053584
On destroying the intrinsic, destroy its contained Allocation right away.
Test: CTS on x86_64 emulator
Change-Id: I5ca0da33b620c3291b7cafda31a6cc83eb7461a0
Bug: 28053769
These objects are tiny and unlikely to cause memory issues.
In addition, llvm-rs-cc auto-generated code contains such objects, which are
not visibible to developers and impossible to manually destroy, leaving
distracting warnings in Strict Mode.
Test: RsTest with StrictMode on and CTS tests
Change-Id: Iec68cca4f1259124b9f503a230c1a28b97ede1f3
Bug: 23159764
Bug: 26862970
- Add detailed description of AutoPadding
- Add comments to all the copy related APIs.
- Fix typos in the comments.
Change-Id: I2d045e0d90efd94f1407f88d3e35bcd42ea93fb9
Bug: 28242626
Bug: 27972184
Bug: 27973681
This is resolving issues in ScriptGroup (V1) again.
In ScriptGroup.destroy(), we also need to consider the old API where
mClosures is not initialized.
Also cleaned up the finalizer for ScriptGroup and Allocation:
Since BaseObj.finalize() calls BaseObj.helpDestroy(), instead of
BaseObj.destroy(), there is no possibility that the finalizers of
child objects may race their parents finalizers. Note that
helpDestroy() does not try to recurse on child objects.
Change-Id: I9dbb2b60f8478f656f8a418c2b5fc8d6848aeef0
Bug: 28242626
ScriptGroup finalizer clears out the list of closures, which is
uninitialized for the old API.
Need to check null first, before accessing the list.
Change-Id: Ibf914e17a0878c8c561f823c5f6f6f6619594de1
(cherry picked from commit 07837d6dab331b1693aa3689223b4012012a7fad)
am: ecf094a
* commit 'ecf094ae9d715ac3cff6213fae4c904f9dd791e8':
Fixed ScriptGroup finalizer for old API
Change-Id: Ia673958b883634197077b69aebd8af293088fef0
Bug: 28242626
ScriptGroup finalizer clears out the list of closures, which is
uninitialized for the old API.
Need to check null first, before accessing the list.
Change-Id: Ibf914e17a0878c8c561f823c5f6f6f6619594de1
am: cc24885
* commit 'cc248853c361588eb5429aee5921acbcc1900c8a':
Destroy Type created by Allocation.createSized()
Change-Id: Ic79bbf7fbf1a3f9d8f49fdb3a3950b0383bc4dcb
am: 1dd551b
* commit '1dd551b019bbbb3a6a61b1a462b63e57e31a5b98':
Fix typos for the word "Unsupported".
Change-Id: I80a9d5f8504e1e2a14595e26fce7079ee490f06e
Bug: 27983025
Device should be destroyed inside the destructor of the associated
Context.
Change-Id: I921a89974e1174f837349a89aef9b03efa4882f5
(cherry picked from commit 4a70df58a32591429ec04902deac2b2210fb96c3)
Bug: 27719830
To turn on warnings, apps have to add to their Activity.onCreate() method
the following code.
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectLeakedClosableObjects()
.penaltyLog()
.build());
For Slang generated ScriptC derived classes, we assume their
constructors won't throw exceptions after calling the ScriptC
constructor. In addition, ScriptIntrinsic derived classes do not seem
to throw exceptions in their constructors either. Therefore, we can
leave the guard.open() call in the Script constructor. This may be
only an approximation, but allows us to add CloseGuard for script
objects without making changes to slang.
Change-Id: I77ed45239a60b85af5c811dee6c124fb53da9060
(cherry picked from commit eb4dd08ec132f83745b8b28fa7da58eb4478b5b9)
Bug: 27719830
To turn on warnings, apps have to add to their Activity.onCreate() method
the following code.
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectLeakedClosableObjects()
.penaltyLog()
.build());
For Slang generated ScriptC derived classes, we assume their
constructors won't throw exceptions after calling the ScriptC
constructor. In addition, ScriptIntrinsic derived classes do not seem
to throw exceptions in their constructors either. Therefore, we can
leave the guard.open() call in the Script constructor. This may be
only an approximation, but allows us to add CloseGuard for script
objects without making changes to slang.
Change-Id: I77ed45239a60b85af5c811dee6c124fb53da9060
Bug: 26916665
- Add description of the endArg.
- Update the example.
- Update the incorrect description.
Change-Id: Idd07db5d790e2d6462fff9cb580115ec45cfd4f0
(cherry picked from commit 53fdcfbe63c1d4b2f1cbee6e72a6dd13f41dc1bc)
