Skip to main content

Isn't it time to build a plugin the allocates memory dynamically???

9 replies [Last post]
Joined: 2008-03-14
Points: 0

Isn't it time to let go of the idea that Java needs to have
the amount of memory an applet is going to run in specified
at startup time?

Isn't it time to construct a JVM/Plugin that will allocate
memory dynamically on an as needed basis like every other
piece of software on the planet?

First, there's the default limit that is imposed on applets
of around 96meg or less. That's not a lot of memory to start

For example: right now I'm most interested in panoramic
photography and publishing panoramas on the web. A more
or less middle of the road size for a pano is around
5000 x 2500 pixels. That only gives adequate resolution
when viewed in a browser by a pano viewer. Pano viewers
generally will take a viewport of between 600x400 to
full screen size to show a portion of that picture.

At 24bits plus alpha channel for 32bits per pixel you
get 5000 * 2500 * 4 ~= 50 meg. Then you have what ever
over head the viewer applet takes up and you are real
close to the default memory limit. And if you want to
do something clever like enable hot spots to link to
other images or web activities like sound. Or to just
load another pano of equivalent size -- the memory limit
gets closer and closer to causing your applet to fail.

My little applet fails all the time if the pano I try to
load is too big. That's not real good for business!

But you can get around that by setting the java_arguments
in *MOST* browsers if you are running plugin2.

So we have a limit but we can get around it. But if you
don't your (my) applet can fail. But you can't depend on
being able to set a higher memory limit than the default
limit of 96meg because not everybody is running plugin2
in a browser that supports the features of plugin2.

Which begs the question of why have a specified limit at all
that is guaranteed to cause some applets to fail?

Flash doesn't demand the programmer to specify the amount
of memory it runs in. I don't know of a single, widely used
program that does require the amount of memory it will run in.

The whole idea is a throwback to the 1980's when computer
memory was significantly smaller and much more expensive.

You can buy a gig of memory for what $50 - $60??? Consumer
grade computers come with 1 or 2 gig of memory. And huge
disks for virtual memory. Netbooks have 1 to 2 gig of

But Java applets -- you get 96meg -- one tenth to one twentieth
of the typical physical memory found on consumer level computers
and even less of virtual memory.

The memory limits on Java are about as necessary and modern
as a black and white television and a dial phone.

How about time shifting Java out of the 1980's into the
21'st Millennium?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-10
Points: 0
Joined: 2008-04-21
Points: 0

Your best overall solution is probably to put some kind of version check in your applet to see, if the user is running a plugin2-compatible JRE. (6u10+) If this not is the case, you could offer the user the option to upgrade to 6u11 or newer to get support for the java_arguments parameter.

Not a pretty solution, agreed - but necessary in your case as I see it. The other thread explains why a dynamic upper memory limit isn't that simple...

Another thing is - I don't personally understand, why we should wait for 6u10 to get a parameter like java_arguments for applets, but that's just the way it is... at least it's here now.


Joined: 2008-03-14
Points: 0

Thanks for the link to that other thread. Wasn't aware of it. I hope I'm adding my voice
to the shouts of the surly crowd. Maybe if enough people shout loud enough, the Wall's
of Jericho will tumble...

From that other thread:

"I'm certainly not saying it's easy or trivial, but I'm confident the JVM team could do it if they made it a priority. They've done incredible work with CPU optimization, memory optimization has been ignored however."

That's the way I feel. It's only software. You can make software do [b]ANYTHING [/b]within
the limits of the hardware.

I think the people on the Java Dev Team are smart enough to figure it out.

Or if they are not, then hire people that are.

Or here's an idea -- license Oracle's JVM. Kill two
birds etc. Java gets a modern JVM and they can reduce
their engineering costs by pink slipping the engineers
that can't seem to come up with the solution that Oracle

Joined: 2003-06-10
Points: 0

What you seemed to have missed is that they know how to do it, it is just that there is a performance cost to a fully dynamic upper memory bound. Some people are likely to prefer the existing implementation over a dynamic memory limit that came at the cost of slower operation. Supplying both versions would be possible but that incurs an added support burden --- is it worth it?
It would be nice to know the estimated performance benefit of the fixed upper bound.

P.S. I am regularly using heaps > 1GB.

Joined: 2008-03-14
Points: 0

I admit I know nothing of the internals of the JVM. I would like to know more.

But I wonder if the worries about performance are exaggerated given the speed of computers
these days. Again, consumer level computers are running at 2ghz. And graphics cards
(GPU) are taking a big load off the CPU. And if the garbage collector is the bottleneck
then maybe the garbage collector can be optimized for dynamic memory.

I would use huge heaps also, but in the problems with not everybody running the latest
plugin and/or browsers that support the features of the latest plugin, one still has to
deploy to the lowest common denominator.

And it's the same old story about asking or demanding that users update this or that -- it
aint gonna happen.

One obvious solution is to simply raise the default memory limit
to some more modern value that acknowledges the capability of the
average computer.

That gives a continuous heap -- if that is really important --
for the garbage collector. Then if the applet really
does need more memory, pop the top so to speak. If
it's an applet that really needs huge resources then its
better to take a small performance hit (and I assume small)
than to not run at all.

Joined: 2003-06-10
Points: 0

Machine I'm using is a quad core 2.4GHz and I regularly push all 4 cores to 100% for long periods. The JVM is exactly the same as the one used for your applets (OK sometimes the server version but that has the same characteriestic with respect to heap size). So we have a tradeoff which has a different value for different use scenarios.

I think for your use simply requesting an upper bound of 500M would suffice. If you don't use it you have only reserved address space which costs very little.

Joined: 2008-03-14
Points: 0

I don't see that there's a trade off involved. We don't know how this hypothetical JVM
would perform. If you want to imagine that this imaginary JVM would take a performance
hit when using 4 cores to the max -- ok. Enjoy.

There is no reason why this imaginary JVM could not be started with the same sort of
requests for a particular upper limit of memory as are now imposed and then only
allocate memory dynamically if the need arose.

We can imagine any sort of feature set for this imaginary JVM. It's fun. Give it a try.
How would you like it to act? Imagine the most twisted, conflicted set of requirements
you can. I'll bet the people at SUN are smart enough to implement those requirements
and make it work.

And I regularly put the java_arguments param in my applet tag to request 384meg. But only
those running plugin2 on a select set of browsers (FF3 but not FF2) (IE6 but not IE5) etc.
will get the requested memory. So that means that I still have to program for the lowest
common denominator.

And one of my points is that the default memory limit of 96 meg should be increased to
something useful for modern applets. My other point is that we shouldn't have to specify
any memory limits. That's a throwback to the early days when computers still had
blinky lights showing register values and panel switches.

Joined: 2004-01-07
Points: 0

Why don't you implement it yourself - instead of blaming Sun and telling everybody how stupid the current solution is. All the dynamic heap-setting code is already in place, so the hard work has already been done.

All what you ask for is setting -Xms as large as the available memory, should be a few lines to change.

However I doubt it would be integrated - often things have a reason - they are not just as there are because somebody stupid decided it has to be that way.

So, after all, its the old "my Bug/RFE/Idea is soooo important" thing.

- Clemens

Joined: 2008-03-14
Points: 0