Agreed.. webrev updated.. I inadvertently updated in-place.
Tony
On 2/6/19 2:19 PM, Valerie Peng wrote:
Hi Tony,
Changes look fine, just some nits.
- line 402, 96 bit should be 96-byte?
- line 408, can we not use "l"? It looks too similar to "1"
- As for the comments on line 586, 587, It
Hi Tony,
Changes look fine, just some nits.
- line 402, 96 bit should be 96-byte?
- line 408, can we not use "l"? It looks too similar to "1"
- As for the comments on line 586, 587, It seems to be for the "else"
part of this if-condition. So I find it a bit confusing. Maybe simplify
it to s
Andrew's fix looked much more complicated than running a simple loop in
the byte code. The way I read CompileCommand, I don't think it applies
to intrinsics, or at least I don't see how it relates to make this easier.
The slow start seems to be getting enough attention that addressing it
is p
I'm still not sold on this---it seems like a specific solution to a
single instance of a more general problem.
Have you investigated any tweaks to the JVM or compiler settings? Andrew
prototyped something[1], but it looks like this is also specific to GCM.
A more general solution would be some
I need a review of this change which is to help the AES/GCM intrinsic
activate on large data sizes. It's not the ideal resolution, which
splits up the crypto operation in chucks, but I significantly improves
performance for larger data sizes. Additionally there is an
optimization to not al
On 12/10/18 1:47 PM, Gidon Gershinsky wrote:
> I've run my decryption benchmarks on Java with this patch, with excellent
> results.
> The benchmarks reach the top speed right away, no long warm-up anymore.
> Also, there is no need to split the operation into multiple updates, the
> doFinal works ju
I've run my decryption benchmarks on Java with this patch, with excellent
results.
The benchmarks reach the top speed right away, no long warm-up anymore.
Also, there is no need to split the operation into multiple updates, the
doFinal works just fine.
Moreover, the maximal decryption throughput i
On 11/21/18 5:37 PM, Andrew Haley wrote:
> On 11/15/18 10:42 AM, Gidon Gershinsky wrote:
>> Having the decryption optimized in the HotSpot engine would be ideal.
>
> I agree with you. I did a few experiments, and it can take a very
> long time for C2 compilation to kick in, especially because GCM
Hi all,
Thanks for the prompt feedback on this stuff, appreciated.
1. Analytic queries are often interactive or one-off. A data scientist
would get an on-demand notebook with a Spark cluster (spawned as a K8s
pod), and run a number of queries.
The cluster will be then closed either explicitly, o
On 11/15/18 10:42 AM, Gidon Gershinsky wrote:
> Having the decryption optimized in the HotSpot engine would be ideal.
I agree with you. I did a few experiments, and it can take a very
long time for C2 compilation to kick in, especially because GCM is
glacially slow until the intrinsics are used.
Hi all,
Thanks for the prompt feedback on this stuff, appreciated.
1. Analytic queries are often interactive or one-off. A data scientist
would get an on-demand notebook with a Spark cluster (spawned as a K8s
pod), and run a number of queries.
The cluster will be then closed either explicitly,
I agree with Adam that this is more of a tuning issue and not a problem
with the crypto. Sending multiple updates is a hack.
I've been aware of this bug for a while and I do not understand why this
is a significant problem. The stackoverflow comments say it takes 50
seconds to trigger the in
CCing to core-libs and security.
Based on last comment corresponding java code may need to be re-factored. It is
not simple.
To trigger x64 AES instructions usage early (before JIT compilation kicks in) we may consider call optimized code from
Interpreter similar to CRC32 code. It is also very
I'm adding back in hotspot-dev, because this is a somewhat tricky topic
related to intrinsics and JIT. Hopefully, a Hotspot expert can correct
anything that I say below that is wrong, and suggest any solutions that
I missed.
The AES acceleration is implemented in a HotSpot intrinsic. In order
Dropping hotspot-dev and adding security-dev.
On Wed, 2018-11-14 at 14:39 +0200, Gidon Gershinsky wrote:
> Hi,
>
> We are working on an encryption mechanism at the Apache Parquet -
> that will enable efficient analytics on encrypted data by frameworks
> such as Apache Spark.
> https://github.co
15 matches
Mail list logo
