Timeline for Leak Memory in as few bytes as possible
Current License: CC BY-SA 3.0
24 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 17, 2020 at 9:04 | history | edited | Community Bot |
Commonmark migration
|
|
| May 5, 2020 at 13:59 | comment | added | Olivier Grégoire |
Supplier<String> f = ". "::trim; f.get(); var x = ". "; Now ". " is reclaimed. So this is not a leak.
|
|
| Feb 23, 2017 at 16:47 | comment | added | zeppelin | @Poke - that is true for the dynamically allocated strings in Java 7+ (at least for the HotSpot family of VMs), but a string literal, as used in this answer, won't be garbage collected (as well as it's entry in the intern pool). | |
| Feb 23, 2017 at 14:31 | comment | added | Poke | Personally I like this answer. However I think the best argument against it is that the GC does clean up interned Strings in newer versions (7+) of java. Interned Strings used to be allocated in PermGen but were moved to the heap as of Java 7. Furthermore I think we need better clarification about what a "memory leak" is. The argument I'm seeing is that we can still get a reference to the leaked String. I don't think this matters because we would still have a failure to release that memory even though it's reachable. Failure to release vs lost reference. | |
| Feb 22, 2017 at 13:31 | comment | added | zeppelin | @tenmiles - it is a string literal, so it should not be garbage collected. | |
| Feb 22, 2017 at 13:30 | comment | added | tenmiles | Won't Java garbage collect the original string, thus not making this a memory leak? | |
| Feb 20, 2017 at 15:44 | comment | added | zeppelin |
@user2357112 On a machine with a finite memory, you can access a value stored in any piece of memory simply by guessing it correctly, but that does not mean that such a thing as memory leaks do not exist. there's probably some way to use reflection to determine the string's contents too could you demonstrate this ? (hint, String.intern() is implemented in the native code).
|
|
| Feb 20, 2017 at 15:41 | comment | added | user18932 | @Serverfrog functions are permitted, including lambdas. It is a good idea to include code to invoke the function or explain which functional interface can wrap the lambda, which this answer did. For golfing purposes, however, only the lambda is included in the byte count - not any other "glue" code to include it in a larger program. | |
| Feb 20, 2017 at 15:27 | comment | added | user2357112 | @zeppelin: A memory leak is not when it's unlikely or difficult to reach an object. We can access this string simply by guessing correctly. That's not a leak. (If guessing is somehow a magical superability that doesn't count, we can open and read the .class file, even within the program, and there's probably some way to use reflection to determine the string's contents too.) | |
| Feb 20, 2017 at 11:39 | comment | added | Olivier Grégoire |
@zeppelin You used a specific String, not a random one. So we have access to the code and we can show you that that code isn't unreachable. It isn't a leak. Your best bet if you want to use the string cache is to generate a random String with an unspecified seed and .intern() it. so we can't go back to access the String again. Using any specific String will make it accessible again.
|
|
| Feb 20, 2017 at 10:34 | comment | added | zeppelin | @Serverfrog, I don't think there is a good consensus about it, really. There are well-accepted lambda-based answers (like this one), which do not include all this repeated boilerplate code. Moreover, the method reference, as used in this answer, points to a concrete method of a final class (i.e. it implies more type information than a generic lambda). But I guess that would make a good topic to discuss on Meta. | |
| Feb 20, 2017 at 10:02 | comment | added | Serverfrog | One thing I don't really know how it has to been handled: you can't use this exactly code and run it through javac. So are java answers always (like C# or other languages with that buildup) with all that class and "public static void main" part. | |
| Feb 20, 2017 at 9:40 | comment | added | zeppelin | @user2357112 "...That string isn't even inaccessible..." That only looks obvious because you see the code. Now consider you got this method reference X() as an argument to your code, you know that it allocates (and interns) a string literal inside, but you do not know which one exactly, it might be ". " or "123" or any other string of a (generally) unknown length. Would you please demonstrate how you can still access it, or deallocate the entry in the "intern" pool it occupies? | |
| Feb 20, 2017 at 1:00 | comment | added | user2357112 | That string isn't even inaccessible, let alone leaked. We can retrieve it at any time by interning an equal string. If this were to count, any unused global variable (private static in Java) would be a leak. That's not how memory leaks are defined. | |
| Feb 19, 2017 at 19:37 | comment | added | zeppelin | > You could just as well say that every cache is a memory leak Exactly, if a) What you put into it does not expire by itself b) There is no way to explicitly remove anything from it, or enumerate it's content c) You have lost the key. Now you have a piece of memory allocated for something you can not access or remove any longer, hence it is a leak. And I don't think interned string literals are subject to garbage collection, even in implementations which do GC on the interned strings pool per-se. | |
| Feb 19, 2017 at 19:00 | comment | added | Elist |
Forgive me for saying, I think this is ridiculous. You could just as well say that every cache is a memory leak. The java GC won't clear this memory since it is intentionally reserved for performance reasons - to allow == comparisons (which, anyway, is not entirely true, since interned Strings are weakly-referenced).
|
|
| Feb 19, 2017 at 18:32 | comment | added | VisualMelon | Indeed, the only consensus is slim at best, I'm just firmly on the "the code should compile" side. I'm still not sure I buy this solution given the wording on the question (these strings can't be freed, and they can be found in normal operating code even though it's unlikely), but I invite others to make their own judgement | |
| Feb 19, 2017 at 17:52 | history | edited | zeppelin | CC BY-SA 3.0 |
added 1 character in body
|
| Feb 19, 2017 at 17:52 | comment | added | zeppelin |
>it has to have some type-asserting context I don't think there is a good consensus on Java lambdas currently, and there are well-accepted Java-lambda answers around, which do not provide any explicit type information. But anyway, in this specific case it is not just a lambda, but an object method reference, against the string literal (which only possible type is a concrete final class java.lang.String), pointing to the 0-arg trim() method of it, making it pretty unambiguous.
|
|
| Feb 19, 2017 at 9:26 | comment | added | zeppelin | Yep, if happen to know the string content in advance, which is an "external" piece of information. I.e. consider this is a library function and you do not see the source. | |
| Feb 19, 2017 at 9:19 | comment | added | VisualMelon |
Surly it's just a case of adding two strings together, as in my prior comment, or does intern not work like that? It's perfectly possible, I would say. This answer also is neither a program, nor a self-contained piece of code that leaks memory, as I don't believe it will compile by itself (it has to have some type-asserting context)
|
|
| Feb 19, 2017 at 9:14 | comment | added | zeppelin | @VisualMelon - the reference is lost, so you have to recreate the string content exactly, to be able to access it again, which is pretty much impossible to do programmatically. | |
| Feb 19, 2017 at 9:02 | comment | added | VisualMelon |
I considered this for C#... but I don't think it counts, because as you say you can access that memory by including another string literal. I'd also be interested to know what ("." + " ").intern() would do (if they were user input or w/e, so we discount compiler optimisations).
|
|
| Feb 19, 2017 at 8:31 | history | answered | zeppelin | CC BY-SA 3.0 |