Jump to content
Excelsior Forums
Sign in to follow this  
kyt

App rarely hangs on startup

Recommended Posts

bugs in the JET Optimizer or Runtime (despite it?s a rare case for the matured versions released last years, we must be honest with you

Since that has been brought up...

I have run into crashes on startups often (1 crash in about 500-600 startups).  But I have managed to reduce the problem to ...an infinitely small one -- I never have seen it since the fix.  I never saw such crashes when the application was run as a "byte code". 

OLD CODE DESCRIPTION:

The application's main class uses "invokeLater stuff" to construct and bring up the main form (JFrame) of the application.  The constructor of the frame is quite large -- about 1600 lines of code, mainly dealing with Swing.  Also, a slow (500 ms) utility "javax.swing.Timer" is started at the end of the constructor (This timer updates some portions of the main frame). So the run() in Runnable invoked in the main class goes something like this:

mf = new MF(...);

mf.setVisible(true);

This is a legitimate way to deal with Swing. 

Crash:

Sometimes, when the compiled application started with the old code, I would see the process start in the system monitor (Linux) or task manager (Windows), but the main form would not show up.  If the application was built to show a splash-screen, the splash screen would show and hang forever (the splash-screen was set to close when a form is shown -- Jet feature), but the application process was there (showing in the system monitor). 

NEW CODE DESCRIPTION:

I modified the code.  Now there are sleep(20) calls inserted throughout the constructor -- in about 20 places. The utility timer "starting" call is moved out of constructor into run() of the Runnable. So NOW the run() in Runnable invoked in the main class goes something like this (notice sleeps there too):

mf = new MF(...);

sleep(150);

mf.setVisible(true);

sleep(150);

mf.startTimer();

I use Jet 6.4 Standard on Linux and the other one. JRE 1.6.0_10.  Crashes happened on both. 

Share this post


Link to post
Share on other sites

Please send the sample and the platform spec (Linux flavor/hardware) to Excelsior Support (java at excelsior-usa.com).

We will do check it on our end.

BTW, does the problem appear if you disable the splash screen?

Share this post


Link to post
Share on other sites
does the problem appear if you disable the splash screen?

Yes.

I have to say that the application performs well once it's started.  It's a complex system that talks to some devices and updates many Swing components -- it's a multi-threaded thing that can and does get very intense, but it never hangs or crashes.

I may some day provide a sample, but at this time I don't see that I can do it -- I can't provide the original (I assume you want the source code) and making a working prototype takes time. 

To elaborate on the old code description:

The main form constructor is very simple but long.  It reads a settings file, builds the GUI and starts a simple thread that loads some DLLs and instantiates a file chooser.  The DLLs are not used until after the constructor and the "loading" thread are long finished.

Do you think there is a chance that the problem can be caused by the amount of code that has to be executed in one take without any sleeps?

Also, I noticed that the problem surfaced more often when many application instances were started quickly one after another.

No one saw this problem -- not the QA, not the customers -- just me. So I assume it's very rare.  I run Ubuntu Linux and XP on the same machine -- Dell Precision with 2G memory and a dual 2.4 GHz Intel CPU.  I have never seen this problem one my single core machines.

Some Jet settings:

-compilewithfixedheap-

-gendll-

-genstackalloc+

-genstacktrace-

-global-

-gui-

-ignoreclassduplication+

-ignorememberabsence+

-inline+

-jetcpenablemanualsettings+

-splashcloseonawtwindow-

-splashcloseonclick-

-splashgetfrommanifest-

-classabsence=HANDLE

-compilerheap=0

-heaplimit=245946856

-inlinelimit=50

-inlinetolimit=250

-jetcplastpage:=PageOptions

-jetrt=Classic

-jetvmprop=-Djava.library.path:lib -Djet.jit.fast -Djet.gc.heaplimit:245946856

Share this post


Link to post
Share on other sites
I never saw such crashes when the application was run as a "byte code". 

Unfortunately, it means nothing except that being interpreted, that code seems to work.

-----

Some Jet settings:

  -jetrt=Classic

With the Classic Runtime, applications run slow on dual Intel CPUs (Desktop Runtime is recommended) but we never saw it caused any crashes.

-----

I'm not sure why you call the behavior a crash. As the app hangs, it looks like a thread dead lock caused by a data race.

Remember that by design of Swing, you cannot (should not) manipulate Swing objects outside the Swing event-dispatch thread.

Are you sure that after

  mf.setVisible(true);

this thread does NOT directly manipulate the GUI?

Please check again that SwingUtilities.invokeLater() and SwingUtiltiies.invokeAndWait() methods are used when necessary.

Share this post


Link to post
Share on other sites

Are you sure that after

  mf.setVisible(true);

this thread does NOT directly manipulate the GUI?

Yes, absolutely.  The whole application has been checked and rechecked many times to make sure the Swing single thread (EDT) policy is always followed.

It looks like the execution is not getting to mf.setVisible(true);  This may be caused by some kind of exception in the previous method (the main form constructor).  I will try to catch that exception, if it does indeed exist.

I'm not sure why you call the behavior a crash.

OK, I will call it a hangcident.  ;)

Share this post


Link to post
Share on other sites

I can't reproduce the problem with my old code.  I'm not sure why.  It is possible that some bad code was taken out or there were some other code changes that modified the behavior. 

I will be visiting this issue from time to time.  I have set up a test and logging environment specifically to monitor this issue, so may be I will have news someday. 

Share this post


Link to post
Share on other sites

No news so far .. just a question:

I think this problem may have also be caused by memory allocation issues. If you noticed in settings I allocate objects on Stack.  I had the stack size of about 900 K.  This seems kind of low for the number of GUI and other objects I have to create on startup. 

What do you (Jet run time) do when the size of allocated objects reaches the maximum allowed?  Thanks

Share this post


Link to post
Share on other sites

However, most of the objects in my application that are created on startup are global objects, so they are allocated on the heap.  Still, I think there is a possibility that memory allocation may have issues in some conditions.  Maybe the heap is not growing fast enough sometimes?

I noticed, though, that when the "hangs" happened the process was taking 0% CPU and the allocated memory was about 36 Mb.  I'm not sure how much of that allocated memory was for the heap.

This heap suspicion is just speculation at this point. 

Share this post


Link to post
Share on other sites
What do you (Jet run time) do when the size of allocated objects reaches the maximum allowed?

StackOverflowError is thrown

Maybe the heap is not growing fast enough sometimes?

No,it's not the case

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×