Regards

Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
http://www.javaspecialists.eu
Tel: +30 69 72 850 460
Skype: kabutz



Johan Steyn wrote:
>
>
> public void f() {
>   {
>     byte[] data = new byte[40 * 1024 * 1024];
>   }
>   byte[] data2 = new byte[40 * 1024 * 1042];
> }
>
> I'll leave a detailed discussion of this issue to Heinz as he has
> taken the initiative already with his latest Java Specialist
> newsletter, so I expect he will provide further insight in a follow-up
> newsletter.
>
> For now I'll just say that, if one is aware that some garbage
> collection features are unspecified and dependent on JVM implementors,
> then one will have an idea what to do to reduce the risk of such code
> causing a crash. So, there are some common good practices that will
> make your code "safer" when used in fringe cases.
>
> That said, I for one would prefer to see the JVM specification
> tightened up in such cases so that the behaviour is more predictable
> and without surprizes. Such inconsistencies due to JVM-specific
> implementations are cases of technology "biting back": Just as you
> were getting comfortable and used to the luxury of having a garbage
> collector, it does something unexpected, and now you're stuck with a
> bug that boggles your mind.
>
> This is precisely where I might want a bit more manual control to
> override the behaviour of the automatic garbage collector: where I
> want to be able to explicitly tell the JVM: "I am done with this
> particular chunk of memory, and now I want you to free it up. Now! Not
> when you get around to it. I want you to free it up because I no
> longer need it and I am going to ask you for an even larger chunk of
> memory soon, so release this memory now."
Right, you can easily jump to the wrong conclusions with that code.  It
appears to be that we are "helping" the GC do its work, but we are not
actually.  More to come in the next newsletter :-)
>
> But wait a minute: who am I to order the garbage collector around like
> that? How can it manage memory effectively if I'm constantly
> interfering? Perhaps assigning null is sufficient... and what if I
> learnt that assigning null at the end of a method is redundant, yet I
> need to assign null in some circumstances at the end of a closure? It
> seems inconsistent and yet another thing that I need to remember to
> avoid crashes.
>
> Sigh. What to do? Either the language/JVM specification needs to be
> tightened up to behave in a more consistent and predictable manner, or
> else the programmer needs some form of manual control to override the
> automatic behaviour when he wants to do something less ordinary. But
> allowing certain aspects to differ among JVM implementations seems
> problematic...  and it seems to blur the lines between the language
> and the platform: having a local variable go out of scope affects its
> visibility, but it doesn't necessarily make it available for garbage
> collection.
>
> I find Heinz's second example quite intriguing, mostly because I
> haven't been able to reproduce it:
>
> public class Foo {
>   private int x,y;
>   public void f() {
>     int a = x;
>     y = 3;
>   }
>   public void g() {
>     int b = y;
>     x = 4;
>   }
> }
>
> Heinz, can you show us under what circumstances you could end up with
> a result of a=3 AND b=4?
>
> I've tried and I haven't succeeded in getting such a result - unless I
> invoke either method more than once. You've piqued my curiosity - I'm
> just frustrated now that I cannot achieve the result you mentioned.
Exactly - keep trying, you will probably never manage to cause exactly
that behaviour, but according to the Java Memory Model, such behaviour
can happen.  I won't bore you with an answer, but point to the JMM spec,
will make everything clear (or not ...)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "CTJUG Forum" group.
To post to this group, send email to CTJUG-Forum@goog...
To unsubscribe from this group, send email to CTJUG-Forum-unsubscribe@goog...
For more options, visit this group at http://groups.google.com/group/CTJUG-Forum
For the ctjug home page see http://www.ctjug.org.za
For jobs see http://gamatamjobs.appspot.com/
-~----------~----~----~----~------~----~------~--~---