**** BEGIN LOGGING AT Mon Jun 27 02:59:58 2016 Jun 27 04:01:53 hey guys, I'm getting very wacky behavior where adding a loop inside a file compiled with -O2 causes a crash on assigning to a global int variable... with ARM64. what gives? Jun 27 04:02:25 My activity just crashed.. what to do? Jun 27 04:03:05 purplex88: :) Jun 27 04:03:10 what to do!! Jun 27 04:03:17 android.content.ActivityNotFoundException: Unable to find explicit activity class Jun 27 04:05:46 Ah.. Jun 27 04:05:55 Forgot to add it to XML Jun 27 04:06:04 Manifest. Jun 27 04:06:29 The Manifest! always happy to bite you. Jun 27 04:06:33 ESphynx: Java loop? Jun 27 04:06:43 purplex88: an eC loop, in fact. Jun 27 04:07:02 it's completely non-sense! the loop does nothing at all! Jun 27 04:07:37 for( index = 0 ; index < value; index++ ) if(index >= areaCount) printf("OH NO!\n"); Jun 27 04:07:47 eC? Jun 27 04:07:51 I leave this in, compile the file with -O2, crashes easily . Jun 27 04:08:04 I comment this out, compiled with -O2, works fine. If I don't compile with -O2 , either way still works fine. Jun 27 04:08:11 It looks like a Java loop Jun 27 04:08:13 Yes eC ( http://ec-lang.org ) Jun 27 04:08:19 Oh Jun 27 04:08:25 well eC is a C superset, like Java, C++, C# :P Jun 27 04:08:49 well, a bit more a superset than those 3 ;) Jun 27 04:09:18 Ah so many languages these days can be used to work with Android.. Jun 27 04:10:04 I just cannot make any sense out of this! Jun 27 04:10:11 What is the value? Jun 27 04:10:41 'value' ? I'm not sure, it changes :P Jun 27 04:10:59 Are you sure it crashes inside the loop? hmm Jun 27 04:11:08 it's actually not crashing inside the loop Jun 27 04:11:14 it crashes later on a assigning a value to a global int! Jun 27 04:11:24 but if I comment out that loop, no problem Jun 27 04:11:32 and if I don't compile that particular file with -O2, no problem Jun 27 04:11:53 at this point I think it's a compiler bug... Jun 27 04:12:13 Ah, try recompiling the whole thing Jun 27 04:12:33 Yeah could be bug Jun 27 04:13:06 some optimization error maybe Jun 27 04:13:59 yeah sounds very much like it :( Jun 27 04:14:10 I did try to recompile the whole thing, now I should probably try updating the NDK Jun 27 04:14:22 but I'm scared something breaks everytime I update anything :P Jun 27 04:14:41 Try changing the loop a bit Jun 27 04:15:12 wll this loop is so basic :P Jun 27 04:16:10 ah actually maybe I could try the 'aarch64-linux-android-clang3.6' Jun 27 04:17:48 hmm that's not installed/prebuilt yet :P Jun 27 04:18:22 Could it be interger overflow exception? Jun 27 04:18:46 in case the global variable is not same type as assignment Jun 27 04:20:45 I doubt it :P Jun 27 04:26:10 well apparently this 10e revision of the NDK is the last one that shipped with GCC by default :P Jun 27 04:26:56 there's good chances my problem will go away by completely changing the compiler ;) Jun 27 04:30:16 ESphynx: yes I was just going to suggest that Jun 27 04:30:54 I always keep more than one compiler :P Jun 27 04:32:16 Still crashes with the GCC 4.9 included in the NDK12 Jun 27 04:32:38 I'll try to see if I can build with Clang :S Jun 27 04:32:46 Hmm Jun 27 04:33:35 If not, then you will need to make sure it is the optimization error Jun 27 04:36:07 not sure how to configure clang though :S Jun 27 04:36:14 I get this: Linker Error: : unrecognised emulation mode: elf_x86_64 Jun 27 04:40:54 Guess -target arm64v8a-none-eabi would help :P Jun 27 04:41:16 i guess too Jun 27 04:42:35 "After some years Stockholm Syndrome kicks in and you start liking the decent bits, namely layouts and little else." this guy read my mind O.o Jun 27 04:44:27 That thread was a train wreck Jun 27 04:44:33 Should it be arm64v8a-linux-eabi ? Jun 27 04:45:39 that doesn't seem to define __linux__ Jun 27 04:46:02 #define __linux__ 1 Jun 27 04:46:04 done ! Jun 27 04:47:08 g00s: tried that :P Jun 27 04:47:23 I guess those errors either way: Relocations in generic ELF (EM: 183) Jun 27 04:57:59 CedricBeust lol the fused location provider gives stale data with current timestamps? i have to check that Jun 27 04:58:53 i thought the old non-GMS gps stuff was easy enough - although its geofencing was pretty busted Jun 27 05:02:38 but i generally agree with pokoito guy. if you make some internet enabled app that sends rest requests to some server, its pretty straightforward ... start using any of the sensors, hw apis, BLE, camera - basically the stuff that makes mobile interesting because of /context/ and it goes downhill fast Jun 27 05:03:38 i remember reading an article about some popular app that used camera, and it sent the model # back to its service to get correction / bug parameters Jun 27 05:04:14 i got the impression its almost impossible to use the camera correctly w/o lots of compensation for bugs Jun 27 05:04:49 and that is strange given android was originally envisioned for cameras, is my memory serves me correctly Jun 27 05:06:39 add wifi direct to the list Jun 27 05:10:08 ESphynx are you accessing sqlite from native code ? Jun 27 05:11:55 g00s: sqlite? I may be yes Jun 27 05:12:07 ESphynx did you see, there is a change there ... Jun 27 05:12:27 what change? Jun 27 05:12:41 I'm linking in my own sqlit though Jun 27 05:12:43 ESphynx http://android-developers.blogspot.com/2016/06/improving-stability-with-private-cc.html Jun 27 05:12:53 ok then you are safe Jun 27 05:13:33 I'm not targeting those modern versions either Jun 27 05:14:15 in fact my manifest says minSdkVersion="9" but I'm linking against platforms/android-21 at the moment -- is that a potential problem? Jun 27 05:14:31 nope Jun 27 05:14:35 g00s: my problem right now is I can't manage to link anything with Clang :P I get those Relocations in generic ELF errors Jun 27 05:14:58 and Google doesn't tell me anything useful about how to fix this :P Jun 27 05:14:59 a new NDK came out the other day, but i don't use these things Jun 27 05:15:33 ESphynx but i'd still target 24 anyhow Jun 27 05:20:59 this looks like it will be interesting http://www.informit.com/store/effective-debugging-66-specific-ways-to-debug-software-9780134394794 Jun 27 05:24:49 g00s, I'm implementing pictures in my categories listview as you suggested Jun 27 05:25:20 Because I finished the damned LocalActivityManager to modern tabs, with fragments and onsaveInstance rotation junk Jun 27 05:26:23 oh good , LocalActivityManager is gone :) Jun 27 05:27:40 Once I publish...I have some more things to cross off my list Jun 27 05:28:13 Ologn are you using any graphics libs ? Jun 27 05:28:45 g00s, I was familiar with Android Universal Image Loader so I used that Jun 27 05:30:14 Since v. 1 is out and v. 2 is not a big improvement from the user perspective I decided to take the time to do things right...so I use Mark Murpht's ArrayPagerAdapter since it is better than the vanilla Android Jun 27 05:33:13 i'll have to check out that class Jun 27 05:35:48 It's called CWAC-Pager Jun 27 05:37:02 Where could I find a guide how to compil with the NDK/Clang Jun 27 05:37:17 (without using any extra tool) Jun 27 05:50:00 is there any reference for "vdc" commands?? Jun 27 05:51:25 mistry: Please stop spreading your question across channels. Jun 27 05:52:17 LunarEclipse120: i didnt know which channel will respond. btw.. i've seen others doing the same. Jun 27 05:52:29 mistry: And they were told to stop. Jun 27 06:01:13 Will activity level android:theme override application android:theme tag? Jun 27 06:15:07 yes Jun 27 06:41:33 hi everyinoe Jun 27 06:41:51 Hello bash_turtle. Jun 27 06:41:56 kindly help me to appropriatae resources to the android development Jun 27 06:42:05 i wanted to develop the custom roms Jun 27 06:42:10 i am new to android Jun 27 06:42:30 however i am able to get resources for app development only Jun 27 06:42:43 whereas i need the resources for rom development Jun 27 06:42:46 kindly help Jun 27 06:43:48 There is no tutorial for developing ROMs. Jun 27 06:43:57 And a noob defiantly can't do it. Jun 27 06:44:04 bash_turtle, I'm not understanding. Are you talking about writing an app, or writing a native app, or customizing core components of the Linux Operating system or the Java interface components? Jun 27 06:44:55 i am talking about learning the original source code of android from scratch ,building kernels and develop my own custom rom for suiting my beeds Jun 27 06:45:02 like cyanogenmod etc. Jun 27 06:45:12 jesseg: He wants to make a custom ROM. Jun 27 06:45:22 bash_turtle: You aren't going to do that if you are new to Android. Jun 27 06:45:22 bash_turtle, ahhh, you want to know how to get set up to build cyanogenmod? Jun 27 06:45:32 jesseg: He wants to make an actual ROM. Jun 27 06:45:33 now Jun 27 06:45:36 no Jun 27 06:45:44 bash_turtle: It takes years of learning about Android as a whole. Jun 27 06:45:51 ohhh Jun 27 06:45:55 no issues Jun 27 06:45:55 I've been doing this for 2 years and I can't even make a ROM from scratch. Jun 27 06:46:09 but would be helpful if you could tell me how to do it from scratch Jun 27 06:46:18 You can't. Jun 27 06:46:22 It isn't just a guide. Jun 27 06:46:31 There are too many variables and different situation. Jun 27 06:46:33 any starating tips? Jun 27 06:46:33 *situations Jun 27 06:46:39 bash_turtle, best bet would be to get set up to build cyanogenmod from source, and go from there. Jun 27 06:46:43 Don't go right to the end goal. Jun 27 06:46:46 jesseg: Not even that far Jun 27 06:47:05 ok thanks for your help Jun 27 06:47:07 First learn how Android works in general and how to flash ROMs and stuff Jun 27 06:47:17 And why you are doing those steps Jun 27 06:47:31 LunarEclipse120: butbutbut no one under can have any knowledge of any subject, no matter what Jun 27 06:47:50 actually i am trying to do a project Jun 27 06:47:55 Robdgreat: Are you joking about my age? Jun 27 06:47:59 bash_turtle: What project? Jun 27 06:48:19 where you create an app and enter the phone number of the target Jun 27 06:48:27 which sends an sms Jun 27 06:48:27 And? Jun 27 06:48:38 and you can control the webcam of his device :) Jun 27 06:48:43 without the target being aware Jun 27 06:48:45 Oh for fucks sake. Jun 27 06:48:49 That is illegal. Jun 27 06:49:01 So no, don't do that. Jun 27 06:49:05 but it requires me to modify the core secutiyu components of android Jun 27 06:49:10 LunarEclipse120: getting channels confused. I was making fun of the one going on about not being able to be helped by someone younger than he is Jun 27 06:49:19 actually it is my project which o am submitting to mit Jun 27 06:49:31 bash_turtle: Well you aren't going to do it. Jun 27 06:49:33 as a application to masters program Jun 27 06:49:40 bash_turtle: Unless you find a security hole. Jun 27 06:49:50 bash_turtle, you might be able to start here: https://wiki.cyanogenmod.org/w/Development Jun 27 06:50:01 jesseg: That isnt't what he wants. For the 3rd time. Jun 27 06:50:30 bash_turtle: You aren't going to achieve what you want. Jun 27 06:50:52 anyways i ahve develped the app and i am able to send the spam mesage to the target device Jun 27 06:51:08 however the problem i am facing is that the target does not dend back the information Jun 27 06:51:11 bash_turtle: Also, you are in India. MIT is in the US. Jun 27 06:51:25 i know Jun 27 06:51:31 but i am applying there Jun 27 06:51:35 bash_turtle: You can't randomly control a device without some sort of client. Jun 27 06:51:45 i havae develope d a client also Jun 27 06:51:51 to be used as an apk Jun 27 06:51:54 on a device Jun 27 06:52:03 If you have a client running on the target device and then you use SMS to trigger it, then it would work. Jun 27 06:52:10 But you can't do it to any Android device. Jun 27 06:52:10 done that Jun 27 06:52:13 issue is Jun 27 06:52:14 LunarEclipse120, many fascinating MIT projects involve custom firmware and demonstrate a principle even though it's not practical on a wide scale basis. Jun 27 06:52:18 Ah ok. Jun 27 06:52:23 i dont waant to install a clint o nthe target device Jun 27 06:52:33 bash_turtle: Well that isn't going to happen. Jun 27 06:52:34 then what will be the use of my projrct ? Jun 27 06:52:44 that is what i am trying to do Jun 27 06:52:50 bash_turtle: What good use will it have anyway? Spying? Jun 27 06:52:55 It is illegal in the US. Jun 27 06:53:11 well if i am doing something it is just out of my interest Jun 27 06:53:20 bash_turtle: Well it isn't going to happen anyway. Jun 27 06:53:24 not illegal or anything Jun 27 06:53:31 ok thanks for your input Jun 27 06:53:54 Unless if you find a security hole. Which takes years of research and knowledge and a team of multiple people. Jun 27 06:53:55 bash_turtle, once you get to where you can compile cyanogenmod and install that on the target device then you can begin going through the source code for Linux and the java interface layer and modifying them as needed. Jun 27 06:54:03 Not to mention most of them were patched already. Jun 27 06:54:06 jesseg: Just stop. Jun 27 06:54:19 jesseg: He wants to be able to do it remotly without touching the device. Jun 27 06:54:27 Which isn't going to happen. Jun 27 06:55:28 bash_turtle, oh, yeah, if you want to be able to spy on the target without updating their firmware then you will have to wait for a security hole to pop up. But examining source code is the best way to find one of those ahead of time. Jun 27 06:55:32 Ah the midnight hours of IRC. Jun 27 06:55:40 Where the trolls and retards lurk. Jun 27 06:56:11 jesseg: He left. Jun 27 06:56:31 well he tried anyway ha ha Jun 27 06:56:49 Lol. Jun 27 06:57:10 I was trying so hard not to call him a retard. Jun 27 06:57:35 Robdgreat: Ah I see. The troll in #android? Jun 27 06:59:35 yeah Jun 27 07:00:16 I hoped you weren't lumping me in with the trolls and retards when I was merely taking the piss out of a troll, myself Jun 27 07:00:24 No. Jun 27 07:00:36 I think I was the retard, right? :P Jun 27 07:00:42 I was specifically talking about the guy in #android and they guy who was just here. Jun 27 07:00:53 jesseg: No, bash_turtle. Jun 27 07:01:00 ahh K :D Jun 27 07:01:17 The troll was a guy in #android named shovel_boss. Jun 27 07:01:25 ahh Jun 27 07:01:30 Saying how I am young and I was spamming the channel. Jun 27 07:01:45 When I was helping someone and all he did was tell people not to listen to me :P Jun 27 07:01:50 Ahh - LOL Jun 27 07:02:23 Good night Jun 27 07:02:32 Night. Jun 27 07:15:50 g00s: https://www.reddit.com/r/androiddev/comments/4pzu41/the_camera2_basic_example_is_over_1000_lines_long/ Jun 27 07:29:10 Hi. Is there a way to know when an object has become weakly reachable? Right now I'm holding a WeakReference to my object and checking every 100 ms if get() returns null. Is there a better way? Jun 27 07:29:44 using finalize() doesn't help as that gets called when the object is Garbage Collected, which can be a long time after it has become weakly reachable Jun 27 07:31:57 WeakReference will hold if object has no strong references and after that gc will kick in Jun 27 07:32:04 it may stay for a while Jun 27 07:33:21 I think you're looking at it in the wrong way Jun 27 07:33:35 WeakReference is for when it'll be nice to have the reference if needed Jun 27 07:33:44 not what you're trying to do from what it reads Jun 27 07:33:55 manixrock: what are you holding a reference to? Jun 27 07:34:23 also, probably having an interface to react to lifecycle events on the referenced object are probably a good idea Jun 27 07:35:33 @thepoosh I have a wrapper class for a GPU Texture, and I want to delete the GPU texture when it's no longer needed. The sooner the better Jun 27 07:35:57 but when is it unneeded? when it's strong-reference count becomes 0 right? Jun 27 07:35:59 ok, so why not react to lifecycle events in the parent? Jun 27 07:36:24 manixrock, that sounds like you're doing something awfully terrible :/ Jun 27 07:36:25 where is that TextureView? Jun 27 07:36:30 +1 Jun 27 07:37:28 @thepoosh I googled "java lifecycle events" but nothing came up about calling a method when an object becomes weakly-reachable Jun 27 07:37:35 manixrock: that is usually where youd use phantomref and not weakref Jun 27 07:37:57 There's also no concept like "weakly reachable" Jun 27 07:37:58 but theres no way to clear it faster than finalize - thats just how gc works Jun 27 07:38:10 if you need faster clearing then close it explicitly Jun 27 07:39:05 the reference is wither there or not, depending on what's the status and type of reference Jun 27 07:39:06 yawkat: but how can I close it explicitly when the only way to to know for sure it's no longer used is to keep a usage cont myself, so basically reimplement the Garbage Collector object pointer thing in my ap Jun 27 07:39:19 usage count* Jun 27 07:39:20 you should not be trying to do the GC work Jun 27 07:39:27 this ain't no cpp Jun 27 07:39:31 manixrock, there is no other way Jun 27 07:39:36 Java GC isn't reference counted Jun 27 07:39:42 or "usage counted" as you say Jun 27 07:39:44 in any case, have a reference while you need it and release it when you don't Jun 27 07:39:45 It's Mark & Sweep Jun 27 07:40:04 manixrock, so yes, you'll have to do reference counting if your application architecture demands that Jun 27 07:41:58 Mavrik: that's what I thought. So right now I'm using a WeakReference and checking every 100ms for when it becomes null. So now when a GPUTexture object is no longer used in one place I just call System.gc() which makes the WeakReference null if it's no longer used, which is exactly what I need with minimal coding Jun 27 07:42:15 that is not a good approach Jun 27 07:42:21 yawkat: why not? Jun 27 07:42:44 because it is not performant, not reliable and non-obvious. Jun 27 07:42:45 because you should react to changes in the lifecycle and not in the reference Jun 27 07:42:49 manixrock, what exactly are you trying to achieve by checking weak reference? Jun 27 07:43:01 manixrock, it'll become null only when GC collected the referenced object Jun 27 07:43:04 and adding a 100MS hook causes the app to context switch every 100 ms Jun 27 07:43:07 So it's the same as using a finalizer Jun 27 07:43:09 Just shit O.o Jun 27 07:43:34 It'll actually add delay to collection. Jun 27 07:43:39 yes, if you got critical resources (stuff that you want freed timely) use explicit resource management Jun 27 07:44:16 Mavrik: I'm ALSO using the finalize() method, but only as fallback. The reason I'm not using finalize() is because that gets called when the object was GC'd, which can be a LONG time after it became weakly-reachable Jun 27 07:44:29 you should never ever call finalize Jun 27 07:44:30 There is NO SUCH THING AS WEAKLY REACHABLE Jun 27 07:44:38 manixrock: it is impossible to know whether an object is weakly reachable before it is collected Jun 27 07:44:44 You're checking for GC Jun 27 07:44:48 what about weekly reachable? Jun 27 07:44:50 once a week Jun 27 07:44:57 Ashiren: oh you... Jun 27 07:45:25 manixrock: you shouldn't be doing the GC work by calling finalize, and you should become aware of the object in a different way Jun 27 07:45:25 and what thepoosh said. relying on finalize is *never* a good thing. there's literally no valid reason to use it. Jun 27 07:45:34 Mavrik: what do you mean? sure there is https://www.google.ro/search?q=java+"weakly+reachable" Jun 27 07:45:49 omg Jun 27 07:46:11 manixrock: the concept of "weakly reachable" is not something you can "check" because by the time you know an object is weakly reachable it has already been collected Jun 27 07:46:16 and finalize has been called Jun 27 07:46:19 thepoosh: I'm not calling finalize() myself, just overwriting it to call my own methods Jun 27 07:46:27 “The Java programming language does not guarantee which thread will invoke the finalize method for any given object. It is guaranteed, however, that the thread that invokes finalize will not be holding any user-visible synchronization locks when finalize is invoked. If an uncaught exception is thrown by the finalize method, the exception is ignored and finalization of that object terminates.” Jun 27 07:46:27 x_x Jun 27 07:46:32 https://developer.android.com/reference/java/lang/Object.html#finalize() Jun 27 07:46:40 manixrock: you are doing it wrong Jun 27 07:46:46 change your sinful ways Jun 27 07:46:48 and repent Jun 27 07:46:58 thepoosh: that quote from the docs is irrelevant though. Jun 27 07:47:17 yawkat: well that's fine too. It's GOOD but not CRITICAL to have it called as soon as possible. Jun 27 07:47:21 true, I was looking for something else and half assed read Jun 27 07:47:21 manixrock, WeakReference.get() will be null only after the object has been collected, so your "weakly reachable" check really checks for GC of the object. Jun 27 07:47:30 manixrock: it will not be called sooner than gc - your solution sucks Jun 27 07:48:27 btw, if you're going to go with your bad solution of overriding finalize you should do it in the referencing object and clean up the Texture Jun 27 07:48:35 and not the other way around Jun 27 07:48:59 but still, it shouldn't be in filalize but in a regular lifecycle event such as onDestroy or onStop Jun 27 07:49:49 Mavrik: again, whether it's weakly-reference or has been GC'd completely are both fine. I no longer use the object, I simply want to know when it's no longer useable in the application so I can free GPU resources (for which I don't need the object itself) Jun 27 07:50:05 I know :) Jun 27 07:50:10 http://stackoverflow.com/a/28906/1056359 Jun 27 07:50:17 You can't know that by using JVM resource system, because of how GC works. Jun 27 07:50:30 It's possible in languages that use reference counting, but not in languages that use M&S like GC Jun 27 07:50:44 So you'll have to implement your own refcounting (or use C++ or find a library for it) Jun 27 07:51:14 netty solves this exact problem by reference counting too Jun 27 07:51:39 though for pooled off-memory buffers, not for textures Jun 27 07:51:42 thepoosh: I don't want to wait until onStop() or onDestroy() are called, it could be hours before those user-dependent methods get called Jun 27 07:51:57 wat Jun 27 07:52:36 thepoosh: again, I'm not calling finalize() myself, only overriding it Jun 27 07:53:07 as I said, you should not be relying on it, and if you are it should be in the referenced object to clean up it's child objects Jun 27 07:53:25 relying on finalize is always a bad solution Jun 27 07:53:37 always meaning also for experienced users Jun 27 07:53:53 this isnt a guideline that applies to most cases, it applies to *all* cases Jun 27 07:54:14 * thepoosh agrees Jun 27 07:55:08 effective java even has a chapter on this - if youre relying on finalization behaviour outside debugging, youre doing something wrong Jun 27 07:55:17 and weak ref checking is no better than finalizers Jun 27 07:56:28 Mavrik: GC is Mark&Sweep I know, but in my tests calling WeakReference.get() returns null, while finalize() hasn't been called yet. After 10 SECONDS I force a manual GC and only THEN does it call finalize() Jun 27 07:56:57 my method detects weak-reachability far faster than relying on finalize() alone Jun 27 07:57:04 do not rely on either behavior Jun 27 07:57:21 manixrock: what are you trying to achieve by that cannot be achieved by listening to normal events? Jun 27 07:57:28 it is certainly vm-specific, and may be device-specific Jun 27 07:57:30 and for the love of god dont call System.gc Jun 27 07:57:38 :D Jun 27 07:57:39 youre seriously fucking up Jun 27 07:59:06 yawkat: I know calling System.gc() is generally really bad practice. But my app uses almost no CPU memory itself, only wrappers for huge GPU objects. I don't really care about java performance Jun 27 07:59:10 if you think you have an excuse to rely on System.gc, weak ref or finalize behavior you are wrong and your code sucks Jun 27 07:59:22 no excuses - dont do it Jun 27 07:59:44 +1 Jun 27 07:59:54 and dont expect sensible improvement suggestions if you do something so blatantly wrong as that Jun 27 08:00:13 there is no way to fix this kind of logic - dont do it, use proper resource management Jun 27 08:00:25 your current approach is broken by design. Jun 27 08:00:26 eyyyy Jun 27 08:00:31 thepoosh: I'm trying to create GPU textures, and use them all over the place in my java code. But at some point when they are no longer used I want to free them. The sooner the better. Jun 27 08:00:50 then you should figure your shit out Jun 27 08:01:05 manixrock: whats stopping you from using automatic resource management such as try-with-resources or lomboks @Cleanup? Jun 27 08:01:20 do your textures ever leave a thread-local scope? Jun 27 08:01:35 if no: use ARM. if yes: use ref counting. Jun 27 08:02:02 But how do I detect when they're no longer used? So I create a dummy java object which gets used in my code. Then I detect when it's no longer being used by checking a WeakReference to it every 100ms, which when its get() returns null I know I can release the GPU resource Jun 27 08:02:32 no, this logic is broken. Jun 27 08:02:53 manixrock: try (MyTexture texture = openTexture("bla")) {} Jun 27 08:03:00 yawkat: try-with-resources only works for small bits of code. my GPUTexture object may be defined in some place, used in 20 different places at different points in time. Jun 27 08:03:09 ah okay. then use ref counting. Jun 27 08:03:31 increment ref counting at the start of that thread-local area where you use the texture, and decrement when youre done. Jun 27 08:04:03 in java there is unfortunately no alternative to that. Jun 27 08:04:28 yawkat: I always have to use the GL thread for those yes. So I use static-defined Runnables as callbacks from other threads so my code runs in the proper thread.. standard GL operations Jun 27 08:06:16 yawkat: ref counting is of course one option I've considered, but if I ever miscount it's trouble. But if I use the native GC and check with a WeakReference like I'm doing now it will work 100% of the time, with the only downside being that it's not instant but has a small delay which is FINE. Jun 27 08:06:30 gc will not work 100% of the time Jun 27 08:06:52 if you have a finite resource that is not memory, general-purpose gc like you get on general-purpose vms is unsuited for managing it Jun 27 08:06:54 yawkat: it won't. But even if it delays for 10 minutes it's also acceptable Jun 27 08:07:09 regional GC is a different story but android does not have a regional GC Jun 27 08:07:32 neither does hotspot for that matter. Jun 27 08:07:36 I've tested on several Android devices and versions 4.0.x-6.0.x and they work fine with my implementation. Jun 27 08:07:45 they work fine by accident. Jun 27 08:09:12 yawkat: if it works by accident, is there any way to test when it will not work? Jun 27 08:09:17 Your solution will work for specific work loads on specific vms on specific devices, but it will never work generally. Jun 27 08:10:36 yawkat: well I can (sorta) test that. I'll test on multiple different Android devices and see if it fails working on any. brb Jun 27 08:10:44 no, you cant. Jun 27 08:10:47 I tested only on 3 so far Jun 27 08:10:50 it will *never* work generally. Jun 27 08:11:01 because the GC does not manage GPU resources. Jun 27 08:11:10 as i said, broken by design. Jun 27 08:11:26 that's like relying on barrier behavior of classes for jvm concurrency. broken. Jun 27 08:12:02 and thats not even mentioning the performance penalty. Jun 27 08:13:18 java performance is not that important to my app Jun 27 08:13:27 sure. Jun 27 08:21:48 manixrock: note that finalizers are a great way to *test* ref counting. ref count should be 0 at collection time. Jun 27 08:21:54 but this is only for debugging purposes. Jun 27 08:25:41 yep Jun 27 08:32:01 oh, and i might come off a bit harsh about this, but that's because this kind of code will lead to unpredictale, unexpected bugs that are impossible to reproduce Jun 27 08:32:18 and i have seen these issues and have had to debug them Jun 27 08:33:50 tested on 9 devices (some old some really new), and they all detected the weak-reference within 100ms of it becoming unused Jun 27 08:34:39 yawkat: I agree. That's why I'm trying to get other opinions before choosing this path. Jun 27 08:35:12 manixrock: the problem is that youre relying on unspecified behavior, behavior that is actively exploited by vms Jun 27 08:35:40 you may not be able to reproduce it and thats the whole issue - when it breaks, and it will, you will be unable to find the issue and fix it Jun 27 08:36:11 my problem with manual usage/reference counting is it's almost impossible to do right. My object or texture-id may be used in other classes, passed as parameters then used at later points in time in Runnable callbacks, and a million other such things. Only the GC knows all these usages 100% correctly. Jun 27 08:36:33 ref counting is cumbersome but it isnt that hard to get right Jun 27 08:36:47 and you can still use finalizers to debug the ref counters Jun 27 08:37:08 yawkat: I think it's almost impossible to get right for all cases. Jun 27 08:37:56 No, actually it's not. But the fact that you're passing these things around async code and runnables show you have an architecture problem. Jun 27 08:38:12 manixrock: i disagree Jun 27 08:38:17 example: I pass my texture-object as a parameter to a method, which calls 10 other methods, several of which spawn a thread which uses the passed texture-object to draw on the scene. How do I do reference count here? Jun 27 08:38:21 And I think this is the point we keep returning to - you kinda didn't architect your application around the limitations of JVM and now keep hitting barriers :/ Jun 27 08:38:33 i have implemented applications using netty ref counting with great success Jun 27 08:38:47 and complex applications with complex data flows at that Jun 27 08:39:46 it takes a while to get used to, but if you structure your application sensibly it is a very managable solution Jun 27 08:39:47 how do i go about storing methods in a list? i'm not sure what to google for. i have several methods with equal method signature, and want to call one depending on a certain condition. Jun 27 08:40:05 as opposed to a big if-structure Jun 27 08:40:21 xorgate: either use a switch case, or anonymous classes, or retrolambda, or reflection. Jun 27 08:40:29 in that order from good to bad. Jun 27 08:41:04 what i was thinking of is something like: Method x = hashmap.get(conditionString); x(params); Jun 27 08:41:13 but i'm not sure what the syntax would be Jun 27 08:41:38 java does not have this, at least not on android without retrolambda. Jun 27 08:41:45 That's something that will make a future you / another developer murder you in your sleep. Jun 27 08:41:54 xorgate: Map myMethods = new HashMap(); myMethods.get(conditionString).run(...); Jun 27 08:41:58 (Even though you can do that with interfaces) Jun 27 08:43:17 yawkat: netty ref counting seems interesting, but I'd rather implement my own since it doesn't avoid the main issue of when to call `buf.retain()` and release Jun 27 08:43:28 hi Jun 27 08:43:53 guys, I wonder if there is any documention on gradle-experimental build system. Jun 27 08:44:00 manixrock: well netty ref counting isnt portable to other kinds of resources anyway but it is an example of a good approach to this Jun 27 08:44:12 Mavrik: being killed in our sleep by future developers is an occupational hazard we all take Jun 27 08:44:15 hero_biz, there's not much, it's marked experimental because it's not ready for wise use Jun 27 08:44:36 I wana use its ndk support Jun 27 08:45:16 I just wanted to see what elements is supported in ndk {} tag. Jun 27 08:45:39 if there is nothing about it, cannot do anything .... Jun 27 08:46:30 Mavrik: "And I think this is the point we keep returning to - you kinda didn't architect your application around the limitations of JVM and now keep hitting barriers" -- I'd like to allow my game engine to be used in many different situations, not limit it to certain usage patterns unless I really have to Jun 27 08:47:24 and this is not a barrier for me really, I've tested it and it seems to work fine on 9+ different devices, I'm simply trying to get more opinions Jun 27 08:48:09 manixrock: gc is unfortunately limited to ram managemet, theres no way around this Jun 27 08:48:45 and if you want other people to use this thing productively you have an even greater responsibility to do it right Jun 27 08:48:59 yawkat: that's why I'm monitoring a CPU/RAM object to know when to release my GPU resources. Jun 27 08:49:19 you have no way to trigger the gc reliably Jun 27 08:49:23 "You tested it on 9+ difference devices" O.o Jun 27 08:49:54 I'm not relying on the GC triggering reliably, only eventually (30+ mins later is still fine) Jun 27 08:50:18