Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of oliver.deakin@googlemail.com
 designates 209.85.218.226 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=dBFfq6dutje1ozXIu4x8avdBJkt6+/UN2uEsinngdHDcvjLxN8+DX9LnhcwxCoLFC1
         50GSHec+bZC1cTcwZ0YJ7E+hkUyDEaw5S3v2fPKcgo92huTbr86fsptLBelAMjWtmDl8
         kFGFTdLWp4TY4bGqGmqANuqdRUwR26Tmn4Ai8=
Message-ID: <4AC471CC.9070602@googlemail.com>
Date: Thu, 01 Oct 2009 10:09:32 +0100
From: Oliver Deakin <oliver.deakin@googlemail.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib] OSResourceMonitor must go
References: <4AC46E87.3040604@gmail.com>
 <200910010904.n9194M0M026935@d12av03.megacenter.de.ibm.com>
In-Reply-To: <200910010904.n9194M0M026935@d12av03.megacenter.de.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Yep, +1 from me as well - this code is too hacky and costly for each malloc.

Regards,
Oliver

Mark Hindess wrote:
> Harsh but fair.  I'm +1 for removing it.  It is a shame there isn't a public
> API but this problem should be handled by applications.
> -Mark.
>
> In message <4AC46E87.3040604@gmail.com>, Tim Ellison writes:
>   
>> I propose that the OSResourceMonitor abomination is removed.  It sits in
>> front of our OSMemory.malloc() calls to check there is enough system memory.
>>
>> First, it is going to make all our regular mallocs (from Java) slow by
>> making these extra JNI + system calls.  At least it should be written to
>> kick-in when an OOM exception is thrown, not on every call!
>>
>> Second, it is there IIRC to attempt to solve the problem of NIO direct
>> byte buffers.  I'm not convinced it will do a good job of that --
>> invoking System.gc() in a loop is hopeful at best, and again taxing
>> every call to malloc up from for this is unreasonable.
>>
>> The current situation is a hack to work around the lack of public API to
>> free a direct byte buffer.  There is a far better hack available, and
>> that is for apps to cast down and call free explicitly, i.e.
>> ((DirectByteBuffer)myBuffer).free()
>>
>> Regards,
>> Tim
>>
>>     
>
>
>
>   

-- 
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU