Quick JDK 8 Suggestion


JDK 7 is just behind that door, and I am really excited about all the goodies that it brings with it.

While I was trying to benchmark JDK7 vs. older JDKs, I realized that the GC(Garbage Collector) is an unknown factor, i.e. while some piece of code is running, one can never know if the GC is running in parallel , in such a case that specific iteration might take much more time, hence the benchmark data will get corrupted.

So my suggestion is adding an awesome new block type: (JDK 8!!!)

no Garbage Collection block – noGC

noGC{

//some code here;

}

catch(AlmostOutOfMemoryError err){

}

While the code inside the noGC block is running, it’s promised that the GC won’t run in parallel

The AlmostOutOfMemoryError will get thrown in case the Heap is X% full (whereas X is configurable as -xnogcf )

Just to be clear, it wouldn’t help me out with benchmarking since the older JDKs do not support it, yet that was the trigger..

how would such a block would work in a multi-threaded environment is another issue..

In my opinion applications with a tiny real-time need would benefit a lot using such a block, much more than all those real-time Java frameworks out there…

Would love to hear your opinion

Advertisements

9 thoughts on “Quick JDK 8 Suggestion

  1. I can tell you that this proposal, at least in this exact form, is never going to be implemented.

    The biggest problem, which ironically is a technical non-issue, that Oracle will have (assuming Oracle behaves in a way similar to Sun) is the new noGC keyword. Since some programs may have used noGC as an identifier, it simply cannot be introduced as new keyword.

    Never since assert as keyword has this been done, and judging by all the “final rethrow” contortions JDK7 is going through, it never will be again. Maybe JDK8 will allow you to prefix a block with one of the already existing keywords, like “transient { … }”, to do what you want.

    Another problem is that this will introduce the additional cost of acquiring a lock before every GC operation, but that’s perhaps not as important.

  2. Why does it have to be implemented as a language feature? This could be easily implemented in the library, especially with the proposed resource management blocks.

    Add a new class (or interface):

    interface GarbageCollectionSuspension extends Closable {
    void close();
    }

    And then add a method to get it to Runtime():
    class Runtime {
    // new method:
    GarbageCollectionSuspension suspendGC();
    }

    Then you can do this:

    try (GarbageCollectionSuspension c = Runtime.suspendGC()) {

    // some code here
    }

  3. New block type for such exotic operation is no go – but you could achive something very similar with stuff like

    UnsafeJVM.setGcEnabled(false);
    {

    } finally {
    UnsafeJVM.setGcEnabled(true);
    }

    or similar – and it requires adding just one class somewhere (probably in sun.* space), with proper permission checking and native hook into main gc.

    Now, even with technical details out of the way, it just won’t happen. What do you expect if you are running almost out of memory? Exception will be thrown and you have to retry – so you anyway, need to handle this situation. You can as well measure time before and after the operation and retry it if it took too long due to gc – if you are into some strange kind of soft realtime where operations have to finish fast and can be retried if they don’t.

    Proper solution to such problems is to use realtime java. It has specially scoped memory area, where you have more control about when and if gc runs at all – plus realtime gc which is guaranteed to never disturb realtime threads.

  4. With a bit of pain they could introduce a new keyword (I guess), but what I find difficult about this idea is that currently very little about GC behavior is ever granted, so they probably want to keep it that way.

  5. Thanks for all the comments,
    I wonder what do you all think about the necessity of such a feature?
    I agree there are many ways to implement it without changing the Java syntax, yet in my opinion my suggestion is the clearest one when it comes to the code layout.
    However the ideas here regarding implementing it, as simple as adding classes to the library are awesome, and I guess more applicable as well!

  6. I think you just try to polluting Java, you should pay and get a realtime version of Java, the GC should be predictable with realtime Java.
    The feature you asked is really useless in the PROD env.

  7. This could be sorted with annotations on scope identifier blocks (i.e., { }). Not sure if that’s been implemented or is going to be implemented though…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s