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.
| Summary: | Shared low memory condition monitor | ||
|---|---|---|---|
| Product: | platform | Reporter: | _ pkuzel <pkuzel> |
| Component: | -- Other -- | Assignee: | issues@platform <issues> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | blocker | CC: | issues |
| Priority: | P2 | Keywords: | API, PERFORMANCE |
| Version: | 3.x | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryNotification.html | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 19484, 38273 | ||
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).
Of course it should use the real API when running on JDK 1.5. 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? 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? 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 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. |
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(); }