Re: Memory Store and JDK 1.2

[Niclas Hedhman <ni...@localbar.com>]

Stefano Mazzocchi wrote:

> Ouch, this is not that useful. I like the newer system in 1.7 that calls
> the cache-cleanup if an OutOfMemory error is caught.

There is one problem with this strategy though.
OutOfMemoryError is not an Exception, and for good reasons. It may occur, theoretically at any instruction
of the JVM, not necessarily at well-defined spots. There are many instances where there is no way to
recover after such an ERROR has occurred, and the application should fail to avoid further grievance.

The SoftReferences are not particularly good either, since they are all reclaimed in a single go, since
the GC has no clue of which would be the best to keep.

BUT, as far as I know, there are ways to hook into the JVM's GC and/or heap manager to be notified of
GC events and low memory conditions. I don't know at this time if it is documented, but the RMI subsystem
uses it even in JDK 1.1.

Niclas

Re: Memory Store and JDK 1.2

[James Duncan Davidson <ja...@eng.sun.com>]

> If we really want to get that close to the JVM (and loose much of our
> portability), then we would be able to do magic stuff with the debug and
> profiling interfaces of Java 1.2....
>
> but do we really want to dive that deep?

No. You really don't. In fact my feeling right now is that you are too deep
anyways.. :) But I haven't read the code yet to really get a feel for what's
really going on, so I won't make any concrete comments until I do.

.duncan

Re: Memory Store and JDK 1.2

[Stefano Mazzocchi <st...@apache.org>]

Niclas Hedhman wrote:
> 
> Stefano Mazzocchi wrote:
> 
> > Ouch, this is not that useful. I like the newer system in 1.7 that calls
> > the cache-cleanup if an OutOfMemory error is caught.
> 
> There is one problem with this strategy though.
> OutOfMemoryError is not an Exception, and for good reasons. It may occur, theoretically at any instruction
> of the JVM, not necessarily at well-defined spots. There are many instances where there is no way to
> recover after such an ERROR has occurred, and the application should fail to avoid further grievance.

You're totally right. In fact, the MemoryStore is not based on catching
OutOfMemory but this is a last resource to avoid this error to come all
the way up to the user. In fact, doesn't the 1.7 system work better than
1.6? I think so. It may not be perfect, but it's a good step forward.
 
> The SoftReferences are not particularly good either, since they are all reclaimed in a single go, since
> the GC has no clue of which would be the best to keep.
> 
> BUT, as far as I know, there are ways to hook into the JVM's GC and/or heap manager to be notified of
> GC events and low memory conditions. I don't know at this time if it is documented, but the RMI subsystem
> uses it even in JDK 1.1.

If we really want to get that close to the JVM (and loose much of our
portability), then we would be able to do magic stuff with the debug and
profiling interfaces of Java 1.2....

but do we really want to dive that deep?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------