harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy,Jing Lv" <firep...@gmail.com>
Subject Re: call for review: (HARMONY-6257) [classlib][luni] - Optimize OSMemory.get/setByteArray
Date Thu, 09 Jul 2009 14:13:04 GMT
Hi,

2009/7/9 Regis <xu.regis@gmail.com>

> Regis wrote:
>
>> Regis Xu (JIRA) wrote:
>>
>>>     [
>>> https://issues.apache.org/jira/browse/HARMONY-6257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>>>
>>> Regis Xu updated HARMONY-6257:
>>> ------------------------------
>>>
>>>    Attachment: HARMONY-6257.diff
>>>
>>>  [classlib][luni] - Optimize OSMemory.get/setByteArray
>>>> -----------------------------------------------------
>>>>
>>>>                Key: HARMONY-6257
>>>>                URL: https://issues.apache.org/jira/browse/HARMONY-6257
>>>>            Project: Harmony
>>>>         Issue Type: Improvement
>>>>         Components: Classlib
>>>>   Affects Versions: 5.0M10
>>>>           Reporter: Regis Xu
>>>>        Attachments: HARMONY-6257.diff
>>>>
>>>>
>>>> in getByteArray, use SetByteArrayRegion to avoid memory copy from java
>>>> to native
>>>> in setByteArray, Get/ReleasePrimitiveArrayCritical instead of
>>>> GetByteArrayElements/ReleaseByteArrayElements to avoid memory copy.
>>>>
>>>
>>>
>> I just found in OSMemory.c, get/setByteArray do some unnecessary memory
>> copies between Java and native.
>>
>> In getByteArray, GetByteArrayElements copy data from java to native, and
>> then ReleaseByteArrayElements do the reverse, I think using
>> SetByteArrayRegion is enough.
>>
>
+1 for this fix


>
>> In setByteArray, I found JNI calls
>> GetPrimitiveArrayCritical/ReleasePrimitiveArrayCritical could get a pointer
>> to the primitive array without any copy, but seems they has some side
>> effects (on GC?), I don't have much confidence that they can apply here. I
>> hope some one can give some advices about this patch. Thanks.
>>
>>
As I know, use this GetPrimitiveArrayCritical is something like entering the
"critical region", the spec reads:

After calling GetPrimitiveArrayCritical, the native code should not run for
an extended period of time before it calls ReleasePrimitiveArrayCritical. We
must treat the code inside this pair of functions as running in a "critical
region." Inside a critical region, native code must not call other JNI
functions, or any system call that may cause the current thread to block and
wait for another Java thread. (For example, the current thread must not call
read on a stream being written by another Java thread.)

thus it may potentially stall GC, as well as other jni critical section is
delayed, so this may cause another performance degradation.
So the question is, how key is this improvement,  and what benchmark show
its improvement? I am not sure, it may be in some environment/situations,
e.g. in some small heap environment, this modification may be a little
slower?  We'd better do some more benchmarks?


>
> The patch passed all luni and nio tests, if no one objected, I'd like to
> commit it.
>
> --
> Best Regards,
> Regis.
>



-- 

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

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