4 ms·

Stop being so dismissive of this being a problem. I've had lots of problems with runaway allocation rates in parsers due to this issue. They could at least have

Stop being so dismissive of this being a problem. I've had lots of problems with runaway allocation rates in parsers due to this issue. They could at least have introduced an alternative method which returns a view into the original String IMO. Not everyone is silly enough to not read the doc and get confused when memory blows up.

the8472 11y ago
> and get confused when memory blows up this is fairly easy to spot with a profiler though
- strictfp 11y ago
  Yes that is what I mean. Is it really more common that people do substring and expect the rest to be thrown away than the other way around? I would like to argue that this is an optimization aimed at sloppy code while it's penalizing well-written code.
  - jaawn 11y ago
    I would say: definitely yes. I definitely think it is more common for a programmer to expect that if they make a substring, and never reference the original string again, only the substring would remain in memory after GC. It is more intuitive. Without prior knowledge of the implementation, why would you expect a reference to a substring to hold the entire original string in memory? I don't think it is necessarily sloppy code to interpret the method this way when you do not know the underlying implementation. The description in the Java 7 API for substring is "Returns a new string that is a substring of this string." That does not suggest any sharing with the parent string; it says "new string".
    - strictfp 11y ago
      OK I agree that it's more logical from a GC point of view. But why would you end up with a gigantic string? Are you not doing something wrong then? Anyway, I have moderately sized strings and am trying to analyze parts of them. And I don't want to make copies for the sake of analysis. This has to be quite common as well.

4 ms·

Stop being so dismissive of this being a problem. I've had lots of problems with runaway allocation rates in parsers due to this issue. They could at least have

by strictfp 11y ago

the8472 11y ago
> and get confused when memory blows up this is fairly easy to spot with a profiler though
- strictfp 11y ago
  Yes that is what I mean. Is it really more common that people do substring and expect the rest to be thrown away than the other way around? I would like to argue that this is an optimization aimed at sloppy code while it's penalizing well-written code.
  - jaawn 11y ago
    I would say: definitely yes. I definitely think it is more common for a programmer to expect that if they make a substring, and never reference the original string again, only the substring would remain in memory after GC. It is more intuitive. Without prior knowledge of the implementation, why would you expect a reference to a substring to hold the entire original string in memory? I don't think it is necessarily sloppy code to interpret the method this way when you do not know the underlying implementation. The description in the Java 7 API for substring is "Returns a new string that is a substring of this string." That does not suggest any sharing with the parent string; it says "new string".
    - strictfp 11y ago
      OK I agree that it's more logical from a GC point of view. But why would you end up with a gigantic string? Are you not doing something wrong then? Anyway, I have moderately sized strings and am trying to analyze parts of them. And I don't want to make copies for the sake of analysis. This has to be quite common as well.