Geir Magnusson Jr. wrote: > On Feb 4, 2007, at 8:13 PM, Ivan Volosyuk wrote: >> On 2/4/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >>> I'm getting confused on where people think that this problem needs to >>> be managed. Am I misunderstanding that there should be some >>> awareness of this in the classlib or VM natives? Seems like it can >>> be localized. >>> >>> I think that if whoever calls malloc() finds that the system is out >>> of memory, then it's too late. I always thought that VMs manage >>> their conceptual native "heap" (all native resources consumed from >>> OS, including as Robin mentioned, filehandles) in a proactive manner, >>> like they do their java heap. it's clear now that they don't. >>> >>> So when a caller to malloc() gets a null, it should simply throw an >>> OOM, assuming that the runtime environment did all it could to >>> prevent that. >>> >>> Can this be done through portlib, letting the VMs implementation of >>> it manage to whatever degree of sophistication is warranted? >> >> Actually, the portlib is the lowest layer we rely on. If we can have >> here a callback to VM's GC we can place the code in the portlib. I >> would also distinguish memory allocations which associated with java >> objects and that which doesn't. No need to account resources which >> will not be freed after garbage collection. > > That's true. I was just thinking about keeping a clear idea of the > native resource usage, but that's actually a separate concept from > coupling to java objects and their lifecycle.
I agree, and it is generally a good idea for the VM to track it's resource usage through the portlib so that apps can embed the VM with conditions that it uses no more than a given set of limits. The class library can do the same thing in the core libraries, but it soon gets out of hand when you start interacting with more third-party libraries that are not telling you about their resource usage, or have limits of their own (such as GUI libraries). >> As was mentioned we have different types of critical system resources. >> It makes sense to make a list of such resources: >> malloc'ed memory >> mmap'ed memory >> shared memory (?) >> file descriptors (files, sockets) >> XWin / GDI resources (?) >> more? >> >> What would be the accounting strategy for the resources? We could >> allocate them via some functions in this facility or we could only >> account them here and call GC using some buildin criteria. > > It's clear to me that accounting and "free when associated java object > is free" are two different notions... Yes. Regards, Tim
