That's pretty cool. I'm curious: Does -Xcomp work because it can show
the variable doesn't escape, or because of deadcode elimination? For
example, when implementing an InputStream, one way to implement read would
be:
@Override
public int read() {
byte[] onebyte = new byte[1];
int ret = read(onebyte, 0, 1);
if (ret == -1) {
return -1;
}
return 0xFF & onebyte[0];
}
How can I tell that the compiler knows onebyte array doesn't escape?
On Thu, Jan 25, 2018 at 12:13 AM, Aleksey Shipilev <
[email protected]> wrote:
> On 01/25/2018 03:44 AM, 'Carl Mastrangelo' via mechanical-sympathy wrote:
> > Consider the following code:
> >
> > public class Test {
> > static volatile Integer discard;
> > public static void main(String [] args) throws InterruptedException {
> > printMemory();
> > System.gc();
> > printMemory();
> > int iterations = 1000;
> > int[] vals = new int[100_000_000];
> > while (args.length == 0) {
> > printMemory();
> > System.gc();
> > Thread.sleep(200);
> > discard = iterations++;
> > }
> > }
> >
> > private static void printMemory() {
> > System.out.println(Runtime.getRuntime().totalMemory() -
> Runtime.getRuntime().freeMemory());
> > }
> > }
> >
> > I am surprised to see the memory used by this code starts at about
> 200MB, goes up to 600MB, but
> > never seems to go back down. The large int array accounts for the
> memory usage jump, but it never
> > seems to be garbage collected. Why? The variable is never read after
> it is allocated. It cannot
> > be reordered by the compiler to be after the while loop, because I can
> see the memory jump. I am
> > intentionally allocating memory in the loop by boxing the integer.
> Enabling +PrintCompilation and
> > PrintInlining never shows main() being inlined; perhaps it is not being
> compiled?
>
> This is not escape analysis. It is more about compiler able to figure out
> the reachability of local
> variable, and let GC act:
> https://shipilev.net/jvm-anatomy-park/8-local-var-reachability/
>
> It is predicated on the condition that method is actually compiled and
> optimized accordingly. OSR
> would not cut it here, I think, because the OSR version of the method
> would still treat that
> variable alive.
>
> $ java Test
> 10548688
> 260648
> 410809368
> 410673344
> 400260544
> 400260544
> 400260544
> 400260544
> 400260544
> 400260544
>
> It changes if you compile the method before entering it:
>
> $ java -Xcomp Test
> 73841024
> 296240
> 421393656
> 10580272
> 10580608
> 10580608
> 10580608
> 10580608
>
> Thanks,
> -Aleksey
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "mechanical-sympathy" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/mechanical-sympathy/hj5VaYIoNiE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
