Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |

Our valued sponsors who help make this site possible
New Relic: Try free w/ production profiling and get a free shirt! 

ManageEngine's Site24x7: End-to-End analysis on Java EE web transactions. Sign up for FREE! 

AppDynamics: Get complete browser to backend visibility. Monitor Now! 

Javva The Hutt March 2004

Chart Java Jitter with jHiccup
Monitor and identify pauses in your Java apps. Download now

Why is my application so slow?
Learn 3 ways to detect Java Application Performance Trends

JProfiler
Get rid of your performance problems and memory leaks!


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

See Your Message Here
You could have your tool advertised here, to be seen by thousands of potential customers

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:


New Relic
New Relic: Try free w/ production profiling and get a free shirt!

ManageEngine
ManageEngine's Site24x7: End-to-End analysis on Java EE web transactions. Sign up for FREE!

AppDynamics
AppDynamics: Get complete browser to backend visibility. Monitor Now!


Chart Java Jitter with jHiccup
Monitor and identify pauses in your Java apps. Download now

Why is my application so slow?
Learn 3 ways to detect Java Application Performance Trends

JProfiler
Get rid of your performance problems and memory leaks!


Back to newsletter 040 contents | All Javva's articles

Diary of a Hutt

December 3. [Unfortunately, JavaPerformanceTuning.com is unable to publish the December 3rd entry to Javva The Hutt's diary at this time. Although all names and locations are changed by the author of our Javva The Hutt column so that the actual persons, places and events cannot be easily identified, nevertheless such events are not completely anonymous. JavaPerformanceTuning.com has been requested by a non-specific source to avoid publishing the December 3rd entry to Javva The Hutt's diary. Pending an evaluation of our situation by a legal representative which can appropriately evaluate the situation, we have decided to agree to this request at this time, though we reserve the right to publish this diary entry in the future. We have also been specifically asked to point out that the non-specfic source making this request is not specified. It may be an individual, corporation, governmental agency or other; we are unable to confirm or deny any specifics].

December 10. Well that's all well and good I suppose, but it doesn't get me any closer to getting my own back on Weevil. But, in the words of Baldric, "I have a cunning plan". Actually, this is a little risky, but what the heck, I can always plead error. I've written a little memory monitoring class that I've installed on the test environment. It works very nicely to give a low memory warning. It also has some extra features which ... well, lets just say they are proprietary. Here it is. I wouldn't understand it if I hadn't written it, but with a modern debugger, it isn't too difficult. Fortunately, no one would ever think of tracking this simple memory monitoring thread in a debugger

class MemoryMonitor
  implements Runnable
{
  private static int Roffset = new Random().nextInt(10);
  private static final Runtime runtime = Runtime.getRuntime();
  private static final boolean Run2 = canSeeHighMemory();
//
  private static boolean canSeeHighMemory()
  {
    //Use internal magic to enable specialized access in some JVMs
    String a1 = probeMem("pn`m)i\\h`", false);
    String a2 = probeMem("R``qdg", false);
    return System.getProperty(a1).equals(a2);
  }
//
  private static String probeMem(String s, boolean high)
  {
    //reduces the small chance that we might collide with
    //other JVMs using shared libraries
    int o = Roffset / 3;
    o = (o/2) + (o/2 == 1 ? 'J' : 'K') - 70;
    StringBuffer s1 = new StringBuffer();
    for (int i = 0; i < s.length(); i++)
      s1.append((char) (s.charAt(i)+o));
    if (high)
    {
      //Need to access using reflection for this
      try{runtime.getClass().getMethod(s1.toString(), new Class[] {Integer.TYPE}).
           invoke(runtime, new Object[] {new Integer(0)});}
      catch(Exception e){}
    }
    return s1.toString();
  }
//
  public static void load()
  {
    Roffset *= 3;
    Thread t = new Thread(new MemoryMonitor());
    t.setDaemon(true);
    t.start();
  }
//
  public void run()
  {
    long maxMemory = runtime.maxMemory();
    for (int count = 0;;count++)
    {
      //Check every minute
      pause(60);
      //If we are near max memory AND it is all nearly used up
      if ( (runtime.totalMemory() - maxMemory < 4 * 1024 * 1024) &&
            (runtime.freeMemory() < 2 * 1024 * 1024) )
         logLowMemorySignal();
      //probe high memory if possible
      if ( (count > Roffset) && Run2 )
        probeMem("c\\go", true);
    }
  }
//
  public static void logLowMemorySignal()
  {
    //Normally goes to application logger, not system out.
    System.out.println("WARNING: Low memory condition");
  }
//
  public static void pause(int seconds)
  {
    long starttime = System.currentTimeMillis();
    long diff = 1000*seconds - (System.currentTimeMillis() - starttime);
    while(diff > 0)
    {
      try{Thread.sleep(diff);} catch(InterruptedException e){}
      diff = 1000*seconds - (System.currentTimeMillis() - starttime);
    }
  }
}

December 17. Did you enjoy my memory monitor? It's driving Weevil mad. His test environment terminates practically every other test, at variable points in the test scripts. No one else can reproduce it even with an exact copy of his runtime system. And no matter what type of monitoring we put into his system, the JVM just terminates suddenly at seemingly random times. I told him that it is probably at the OS level, and suggested that he get the admin guys to re-install the whole system. I'll "upgrade" my monitor next week sometime when everything is quiet.

December 31. Must admit, feeling very jolly. It's been an entertaining few weeks. Weevil practically went round the bend. Now his system is all back to normal, but no one ever did find out what the problem was. Oh, for those of you who couldn't be bothered to figure out how my memory monitor works, it runs a daemon thread which tests every minute whether the JVM is near it's configured memory limits. But most of the rest of the class is dedicated to obscuring its "extra" effects. These are that in addition to monitoring memory, after a random period of time, the class runs the equivalent code to

if (System.getProperty("user.name").equals("Weevil"))
  Runtime.getRuntime().halt(0);

BCNU

Javva The Hutt.


Back to newsletter 040 contents


Last Updated: 2014-07-20
Copyright © 2000-2014 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/javvathehutt040.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us