Hi, I see why the compiler should be able to remove the first assignment, but (just for fun) I'm having trouble getting it to actually do it. With my -Xmx setting, I should see an OutOfMemoryError as soon as the first assignment is optimized away because the heap is large enough for only 1 copy of the new byte[] in the second assignment.
So, I'm wondering if this can actually happen. And if not, is it because the JIT just doesn't detect this possible optimization, or because it's smart enough to realize the trick I'm trying to play on it. -Meg On Tuesday, November 13, 2018 at 1:05:43 PM UTC-5, Jean-Philippe BEMPEL wrote: > > Hi, > > JIT Compiler is allowed to discard the null assisgnment because there are > 2 consecutives writes into the same location, so only the last one can be > kept without changing the meaning of the program. > From the GC point of view as soon as the reference is no longer pointing > to the allocate object, it is considered as dead, and may be reclaimed in > the next cycle. > But depending on if data is a field or local variable will determine if GC > can reclaim it sooner. > In the case of a local variable as soon as the variable is no more read, a > GC can already collect the byte[] before assigning local variable to null > (with the help of liveness analysis). > For the field case, the byte[] will reclaimable once the assignment is > done, so maybe after the allocation of the second byte[] > > Regards > > On Tue, Nov 13, 2018 at 6:28 PM Shevek <[email protected] <javascript:>> > wrote: > >> Given the following code: >> >> byte[] data = ...; >> >> { >> data = null; >> data = new byte[N]; >> } >> >> Is the compiler allowed to discard the assignment of null, because it's >> "dead" in language terms? My argument is that it isn't dead because it >> allows the garbage collector to respond to pressure within the 'new' and >> reuse the space, but in language terms, this presumably isn't defined, >> and it would seem to be legal for the first assignment to be removed. >> >> Thank you. >> >> S. >> >> -- >> 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] <javascript:>. >> 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.
