On 2016-02-10 02:03, Paul Sandoz wrote:
On 10 Feb 2016, at 04:42, Mikael Vidstedt wrote:
Can I please get a quick review of these updated webrevs:
hotspot:
http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.05/hotspot/webrev/
jdk: http://cr.openjdk.java.net/~mikael/webrevs/8141491/w
> On 10 Feb 2016, at 04:42, Mikael Vidstedt wrote:
>
>
> Can I please get a quick review of these updated webrevs:
>
> hotspot:
> http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.05/hotspot/webrev/
> jdk: http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.05/jdk/webrev/
>
> i
On 10/02/2016 1:42 PM, Mikael Vidstedt wrote:
Can I please get a quick review of these updated webrevs:
In terms of the incremental changes this looks fine. If you consider it
all reviewed then nothing in the increments should change that.
But looking at the JDK code I have some follow up s
Can I please get a quick review of these updated webrevs:
hotspot:
http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.05/hotspot/webrev/
jdk:
http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.05/jdk/webrev/
incremental webrevs:
hotspot:
http://cr.openjdk.java.net/~mikael/web
On 6/02/2016 8:21 AM, Mikael Vidstedt wrote:
I fully agree that moving the arguments checking up to Java makes more
sense, and I've prepared new webrevs which do exactly that, including
changes to address the other feedback from David, John and others:
Shouldn't the lowest-level do_conjoint_sw
I fully agree that moving the arguments checking up to Java makes more
sense, and I've prepared new webrevs which do exactly that, including
changes to address the other feedback from David, John and others:
hotspot:
http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.04/hotspot/webrev
Hi,
Nice use of C++ templates :-)
Overall looks good.
I too would prefer if we could move the argument checking out, perhaps even to
the point of requiring callers do that rather than providing another method,
for example for Buffer i think the arguments are known to be valid? I think in
eith
On 2016-02-04 04:22, Andrew Haley wrote:
On 02/02/2016 07:25 PM, Mikael Vidstedt wrote:
Please review this change which introduces a Copy::conjoint_swap and an
Unsafe.copySwapMemory method to call it from Java, along with the
necessary changes to have java.nio.Bits call it instead of the Bits.
On 02/02/2016 07:25 PM, Mikael Vidstedt wrote:
> Please review this change which introduces a Copy::conjoint_swap and an
> Unsafe.copySwapMemory method to call it from Java, along with the
> necessary changes to have java.nio.Bits call it instead of the Bits.c code.
>
> http://cr.openjdk.java.ne
On Feb 2, 2016, at 11:25 AM, Mikael Vidstedt wrote:
> Please review this change which introduces a Copy::conjoint_swap and an
> Unsafe.copySwapMemory method to call it from Java, along with the necessary
> changes to have java.nio.Bits call it instead of the Bits.c code.
>
> http://cr.openjdk.j
Hi Mikael,
Can't really comment on the bit-twiddling details.
A couple of minor style nits:
- don't put "return" on a line by itself, include the first part of the
return expression
- spaces after commas in template definitions/instantiation
The JVM_ENTRY_FROM_LEAF etc was a little mind twis
On 02/03/2016 04:13 PM, Mikael Vidstedt wrote:
>
> On 2016-02-03 01:43, Andrew Haley wrote:
>> On 02/02/16 19:25, Mikael Vidstedt wrote:
>>> Please review this change which introduces a Copy::conjoint_swap and an
>>> Unsafe.copySwapMemory method to call it from Java, along with the
>>> necessary c
On 2016-02-03 01:43, Andrew Haley wrote:
On 02/02/16 19:25, Mikael Vidstedt wrote:
Please review this change which introduces a Copy::conjoint_swap and an
Unsafe.copySwapMemory method to call it from Java, along with the
necessary changes to have java.nio.Bits call it instead of the Bits.c code
On 02/02/16 19:25, Mikael Vidstedt wrote:
> Please review this change which introduces a Copy::conjoint_swap and an
> Unsafe.copySwapMemory method to call it from Java, along with the
> necessary changes to have java.nio.Bits call it instead of the Bits.c code.
There doesn't seem to be any way t
Please review this change which introduces a Copy::conjoint_swap and an
Unsafe.copySwapMemory method to call it from Java, along with the
necessary changes to have java.nio.Bits call it instead of the Bits.c code.
http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.03/hotspot/webrev/
ht
Just an FYI:
I'm working on moving all of this to the Hotspot Copy class and bridging
to it via jdk.internal.misc.Unsafe, removing Bits.c altogether. The
implementation is working, and the preliminary performance numbers beat
the pants off of any of the suggested Bits.c implementations (yay!)
On Jan 26, 2016, at 11:08 AM, Andrew Haley wrote:
>
> On 01/26/2016 07:04 PM, John Rose wrote:
>> Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic.
>> IMO that's a better starting point than memcpy. Perhaps it can be
>> given an additional parameter (or overloading) to specify a swa
On 01/26/2016 07:04 PM, John Rose wrote:
> Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic.
> IMO that's a better starting point than memcpy. Perhaps it can be
> given an additional parameter (or overloading) to specify a swap size.
OK, but conjoint_memory_atomic doesn't guarantee t
On Jan 26, 2016, at 10:48 AM, Andrew Haley wrote:
>
> On 01/26/2016 06:32 PM, John Rose wrote:
>> On Jan 26, 2016, at 1:04 AM, Andrew Haley wrote:
>>>
>>> I agree that memcpy is the right thing to use. It's portable and is
>>> inlined well on production-quality C compilers.
>>
>> But it is no
On 01/26/2016 06:32 PM, John Rose wrote:
> On Jan 26, 2016, at 1:04 AM, Andrew Haley wrote:
>>
>> I agree that memcpy is the right thing to use. It's portable and is
>> inlined well on production-quality C compilers.
>
> But it is not strong enough to uphold the Java memory model,
> because it i
On Jan 26, 2016, at 1:04 AM, Andrew Haley wrote:
>
> I agree that memcpy is the right thing to use. It's portable and is
> inlined well on production-quality C compilers.
But it is not strong enough to uphold the Java memory model,
because it is allows to copy byte-wise, which can tear shorts,
On 1/26/16 4:28 AM, Alan Bateman wrote:
On 26/01/2016 04:57, Mikael Vidstedt wrote:
I've finally found some time to return to this and have a new version
of the patch which looks more promising:
http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/
This uses memcpy to read/
On 26/01/2016 04:57, Mikael Vidstedt wrote:
I've finally found some time to return to this and have a new version
of the patch which looks more promising:
http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/
This uses memcpy to read/write the native data and the preliminary
On 26/01/16 04:57, Mikael Vidstedt wrote:
>
> I've finally found some time to return to this and have a new version of
> the patch which looks more promising:
>
> http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/
>
> This uses memcpy to read/write the native data and the prel
I've finally found some time to return to this and have a new version of
the patch which looks more promising:
http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/
This uses memcpy to read/write the native data and the preliminary
benchmark numbers on linux/x64 shows the expe
This is as far as I got before I got interrupted:
http://cr.openjdk.java.net/~mikael/NioBenchmark.java
I haven't had time yet to verify that the benchmark code even measures
the right thing, much less figure out why I get the performance impact
with my fix. I can see many reasons why that cou
On Wed, Nov 25, 2015 at 2:52 PM, wrote:
> Have you looked anything at the performance of the generated code?
No. I looked at the emitted code, saw 'MOVQDU' instruction being used
(it was 'MOVQDA' before that resulted in alignment error), and concluded
that the compiler knows what it's doing :-)
Sending to core-libs mailing list.
On 11/25/15 2:19 PM, Alexander Smundak wrote:
Please take a look at
http://cr.openjdk.java.net/~asmundak/8141491/jdk/webrev.00
that fixes the problem.
It utilizes the ability of some (GCC and Clang) to declare data
alignment explicitly.
I have verified it work
Have you looked anything at the performance of the generated code? As
you may have seen I was playing around with an alternative
implementation[1] which has the benefit of being pure C++ without
compiler specific hints. That said, when I did some initial benchmarking
of that it did seem like
29 matches
Mail list logo
