If the method returns negative flag (should run GC) then after GC invocation the malloc should be allocated, so the native method could 1) call GC from native code (come back to java) and then alloc memory or 2) (this way is implemented by the patch) return to java and java-code will call malloc after GC. Or you suggest to malloc before calling GC in any case?
Thanks, Mikhail On 5/23/07, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
2007/5/23, Alexei Zakharov <[EMAIL PROTECTED]>: > As far as I know DRLVM does not run on kernels older than 2.6 - see > old "building on Debian" thread for details [1]. So it looks like in > order to enable Harmony on pre2.6 (and on pre2.3) kernels we will need > to fix our code in several places anyway. And the > hysysinfo_is_system_physical_memory_low() function is not the most > complicated one. > > This way, IMHO current patches for HARMONY-3148 look quite good. And > since the issue itself is rather critical IMO it is not a bad idea to > finally have it fixed and commit patches in their current state. If > later we decide to use other strategy for native memory deallocation > then we can always create another JIRA & patch and fix this. > > BTW, Tim, if you don't have enough time for this (or do not interested > anymore) I could take care of it. I've took it already... :) I had a quick look into the patch and got one question... The patch creates a new class OSResourcesMonitor with the isSystemPhysicalMemoryLowDefault native method. OSMemory.malloc calls this method in the very begining and then call another native method to allocate memory. Why do we need two native calls here if we can check the native heap size in the native method which allocates it? This method can return a flag to run GC... Did I miss something? SY, Alexey
