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
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.3040...@gmail.com, Tim Ellison writes:
I propose that the OSResourceMonitor abomination is removed. It sits in
front of our
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.3040...@gmail.com,
On 01/Oct/2009 10:04, 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.
I'm going to take it out pronto. I realize it doesn't give people long
to object, but even if the consensus is that we
+1 from me as well.
Actually I was against this patch from the very beginning since it's useless.
Here is the original JIRA issue:
http://issues.apache.org/jira/browse/HARMONY-3148
Alexey
2009/10/1 Tim Ellison t.p.elli...@gmail.com:
I propose that the OSResourceMonitor abomination is removed.
On 01/Oct/2009 09:55, Tim Ellison wrote:
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 +
On 01/Oct/2009 11:00, Alexey Petrenko wrote:
+1 from me as well.
Actually I was against this patch from the very beginning since it's useless.
Here is the original JIRA issue:
http://issues.apache.org/jira/browse/HARMONY-3148
Thanks Alexey. It has gone now -- so we are all happy again :-)
:)
2009/10/1 Tim Ellison t.p.elli...@gmail.com:
On 01/Oct/2009 11:00, Alexey Petrenko wrote:
+1 from me as well.
Actually I was against this patch from the very beginning since it's useless.
Here is the original JIRA issue:
http://issues.apache.org/jira/browse/HARMONY-3148
Thanks Alexey.
Could somebody please take a look a the patch below and see if they
believe my explanation for why it fixes a findbugs problem in InputStream?
The problem: We have a static, skipBuf, that we only use to read junk
data from the stream when skipping a number of bytes. The static is
lazily
On Thu, Oct 1, 2009 at 7:19 AM, Tim Ellison t.p.elli...@gmail.com wrote:
Could somebody please take a look a the patch below and see if they
believe my explanation for why it fixes a findbugs problem in InputStream?
Looks good to me.
Yes, this should fix the concurrency problem.
Tim Ellison wrote:
Could somebody please take a look a the patch below and see if they
believe my explanation for why it fixes a findbugs problem in InputStream?
The problem: We have a static, skipBuf, that we only use to read junk
data from the stream when skipping a number of bytes. The
Thanks guys, fixed at r820776.
Regards,
Tim
On 01/Oct/2009 18:11, Oliver Deakin wrote:
Tim Ellison wrote:
Could somebody please take a look a the patch below and see if they
believe my explanation for why it fixes a findbugs problem in
InputStream?
The problem: We have a static, skipBuf,
Sorry I wasn't moving fast enough for you ;-/
Hopefully you'll nip in and fix the ~1,700 warnings too!
Regards,
Tim
On 01/Oct/2009 15:07, hinde...@apache.org wrote:
Author: hindessm
Date: Thu Oct 1 14:07:04 2009
New Revision: 820665
URL: http://svn.apache.org/viewvc?rev=820665view=rev
In message 4ac5144b.4080...@gmail.com, Tim Ellison writes:
Sorry I wasn't moving fast enough for you ;-/
Well, I'd made the change in my local workspace and knew that Oliver was
looking at some other modules too so I thought I'd get it checked in to
save anyone else doing it.
I guess I just
14 matches
Mail list logo
