JEP 411: Sandboxing v's LOTJ (language other than Java) running on top of Java class libraries / JVM.
I have established it's not practical to implement agents to intercept Java class libraries (Not the JVM) to guard access, such as class loading, properties, IO, etc. It's also not practical to construct a Sandbox using ClassLoader, as has been suggested: 1. We would have to prevent access to java.lang.Class, to prevent code escaping the sandbox, this is far too restrictive. 2. It isn't practical to dynamically grant access, from within a sandbox. 3. The sandbox is an all or nothing approach. 4. The sandbox isn't an authorization layer. Clearly Java in future, will be a zone of implicit trust, similarly to how we use C today from Java. We need a "safer" language than Java, just like Java was a "safer" language than C. This "safer" language would then allow authorization access controls, for network, file, class loading, data parsing, etc. Rather than a sandbox, it just needs to be safer, with the ability to allow access to the underlying Java / C / etc, to trusted / authenticated / verified entities. If anyone has any ideas regarding suitable languages, I'd be very interested to hear your thoughts. -- Regards, Peter Firmstone
Integrated: 8270317: Large Allocation in CipherSuite
On Wed, 14 Jul 2021 17:06:02 GMT, Clive Verghese wrote: > ### Benchmark results > > I have benchmarked 3 cases. > > 1. The current situation. > > Benchmark > (cipherSuite) Mode CntScore Error Units > CipherSuiteBench.benchmarkCipherSuite > TLS_AES_256_GCM_SHA384 avgt 25 124.783 ? 2.050 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 125.403 ? 0.554 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 127.117 ? 0.789 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 127.869 ? 1.112 ns/op > > > 2. Use `static final array` instead of calling `CipherSuite.values` each > time. > > Benchmark > (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite > TLS_AES_256_GCM_SHA384 avgt 25 10.146 ? 0.252 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 30.501 ? 0.207 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 47.375 ? 0.150 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 55.887 ? 3.786 ns/op > > > 3. Using Hashmap for lookup instead of iterating through the array each time. > (Method in this PR) > > Benchmark > (cipherSuite) Mode Cnt Score Error Units > CipherSuiteBench.benchmarkCipherSuite > TLS_AES_256_GCM_SHA384 avgt 25 13.533 ? 0.148 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 avgt 25 11.269 ? 0.147 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 avgt 25 11.507 ? 0.107 ns/op > CipherSuiteBench.benchmarkCipherSuite > TLS_DHE_RSA_WITH_AES_256_CBC_SHA avgt 25 10.932 ? 0.146 ns/op > > > I have picked 4 cipher suite from the start of the list and are roughly 10 > positions apart. I have opted to go with HashMap for name and id lookup as > they provide a more consistent times and benchmarks are similar for the first > few cipher suits in the enum as well. This pull request has now been integrated. Changeset: e627caec Author:Clive Verghese Committer: Volker Simonis URL: https://git.openjdk.java.net/jdk/commit/e627caec84c169c99c04e0d355c29b806a0266ed Stats: 151 lines in 2 files changed: 91 ins; 45 del; 15 mod 8270317: Large Allocation in CipherSuite Reviewed-by: xuelei, simonis - PR: https://git.openjdk.java.net/jdk/pull/4783
