This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 42786

Summary: Shared low memory condition monitor
Product: platform Reporter: _ pkuzel <pkuzel>
Component: -- Other --Assignee: issues@platform <issues>
Severity: blocker CC: issues
Priority: P2 Keywords: API, PERFORMANCE
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on:    
Bug Blocks: 19484, 38273    

Description _ pkuzel 2004-05-04 19:10:19 UTC
Promised to be a part of JRE 1.5. 

Could you introduce minimal subset, just fire
event to registered listeners on low memory
condition. I was able to implement it for tasklist
but I do not want to duplicate it for search
utilities again because my implementation holds
soft reference to huge amount of memory and tries
to reclaim it after it's GCed. OOME during
reallocation => low memory conditon. This approach
cannot be reliably used by mutliple modules
because it becomes too indeterministics in such
case. A central place is needed.

 -- --

package org.netbeans.api.runtime;

// Simple subset of fuctionality
// provided by JRE 1.5 management beans
public final class Memory {

   * Starts the runnable once system
   * reaches low memory condition.
  addMemoryListener(MemoryListener run);
  /** Deregister */ 
  removeMemoryListener(MemoryListener run);

public interface MemoryListener extends
EventListener {

  void lowMemoryCondition();

Comment 1 _ pkuzel 2004-05-07 18:41:25 UTC
Well all known use cases can be distinguihed by iterating over some
dataset. For such use cases a simpler API suffices.

public final class Memory {

    * Returns estime of available memory in bytes for
    * subsequent new. Can return little bit lower value
    * than is actually available.
   public int availableMemory();

Implementation for correct JRE can simply call Runtime class; for
broken JREs it must use SoftReference trick (or substitute).
Comment 2 Jesse Glick 2004-05-07 19:15:13 UTC
Of course it should use the real API when running on JDK 1.5.
Comment 3 _ rkubacki 2004-05-11 09:31:40 UTC
We can use management and monitoring API. I am not sure what is
expected action when listener is notified. To postpone any memory
intensive jobs? To release as many object as possible? Save user data
(directly or for future recovery) to avoid data loss?
Comment 4 _ pkuzel 2004-05-11 09:35:36 UTC
Handler logic cannot be shared. E.g. in my search cases I simply stop
search notifying user that results are premature due to OOME.

Radim, do you plan to push this API to promo-D?
Comment 5 _ ttran 2004-05-11 10:41:59 UTC
In D?  It's probably too late.

We need to be 100% clear about the motivation why we want to do this.
 I think it's not about performance per se.  An algorithm should have
a memory ceilling to start with.  If it consumes all the available
memory then it's a bad citizen in the IDE, other features will be
slowed down.

The valid motivation is to recover from near-OOME situation, let the
user saves the files and shut down.  Anything else sounds too
"creative" to me
Comment 6 _ pkuzel 2004-05-11 14:10:51 UTC
I already talked to Radim and we concluded that we do not need to
address dependent issues on all supported JREs for promo-D. I'm able
to functionaly substitute this API by Runtime memory calls for correct
JREs (tested 1.4.2).

Now I got update from J. Chalupa that 1.4.2 and 1.5 are only supported
JREs => so backporting Runtime based logic from tasklist is
final&clean solution.

I do not need this feature anymore.