harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Li" <liyilei1...@gmail.com>
Subject Re: [classlib] H-3148 (OOM when using native memory which is out of GC-control) again
Date Fri, 25 May 2007 12:31:55 GMT
+1 Sometimes we can save another JNI call.

On 5/23/07, Mikhail Markov <mikhail.a.markov@gmail.com> wrote:
>
> +1 for this approach.
> As for removing OSResourcesMonitor - not agree: IMO we should have this
> facility for another code not using OSMemory.malloc() method which wants
> to
> check the conditions for calling GC.
>
> Thanks,
> Mikhail
>
>
> On 5/23/07, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
> >
> > I suggest to call nativeMalloc anyway. nativeMalloc will check the
> > native heap and return null or something if gc is needed whithout real
> > allocation.
> > Java code will check the return value and call gc and nativeMalloc if
> > needed.
> >
> > So the code will look like the following
> >
> > === cut ===
> > public long malloc(long length) throws OutOfMemoryError {
> >    int res = mallocNative(length, true);
> >    if (res == 0) {
> >        System.gc();
> >        res = mallocNative(length, false);
> >    }
> >    return res;
> > }
> > === cut ===
> >
> > === cut ===
> > JNIEXPORT jlong JNICALL
> > Java_org_apache_harmony_luni_platform_OSMemory_mallocNative
> > (JNIEnv * env, jobject thiz, jlong size, jboolean checkHeap)
> > {
> > PORT_ACCESS_FROM_ENV (env);
> >
> > if (checkHeap) {
> >    if (hysysinfo_is_system_physical_memory_low_default()) {
> >      return 0;
> >    }
> > }
> >
> > void *address = hymem_allocate_memory ((UDATA) size);
> >
> > if (address == NULL)
> >    {
> >      throwNewOutOfMemoryError(env, "Insufficient memory available.");
> >    }
> >
> > return (jlong) ((IDATA) address);
> > }
> > === cut ===
> >
> > I think that this approach is better because:
> > 1. In the good case we got up to 2 times less number of native calls.
> > In the worst case we got the same number of native calls.
> > 2. OSResourcesMonitor class becomes unneeded.
> >
> > SY, Alexey
> >
> >
> > 2007/5/23, Mikhail Markov <mikhail.a.markov@gmail.com>:
> > > 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 <alexey.a.petrenko@gmail.com> wrote:
> > > >
> > > > 2007/5/23, Alexei Zakharov <alexei.zakharov@gmail.com>:
> > > > > 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
> > > >
> > >
> >
>



-- 
Leo Li
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message