Sorry, a new updated webrev
http://cr.openjdk.java.net/~weijun/7099399/webrev.02/
Still, no change for the src file. The test now does not check the VM
version anymore. Instead, it sets max heap size to 1024MB. I've tried
some experiments on various systems. 250MB is OK for all client VMs, but
even 512MB is not enough on a windows server VM. Therefore I choose
1024MB, it also makes the test runs faster.
Also, David Holmes warned that a VM might report "Tiered" rather than
"Server".
The test passes on all JPRT platforms. Linux is fast (~1m),
solaris-sparc slower (~4m), and windows slowest (~5m).
I'll look at the memory usage (that is, 6670894) next week.
Thanks
Max
On 10/12/2011 7:19 AM, Sean Mullan wrote:
On 10/11/11 7:32 PM, Weijun Wang wrote:
Hi All
I've updated the webrev at
http://cr.openjdk.java.net/~weijun/7099399/webrev.01/
I would like at least 2 reviewers. It might need to go to 7u2.
The src file is identical to the last version, and I made several
changes to the test:
1. Now run in othervm. Though hasn't made any changes to the VM, the
huge memory footprint might prevent other tests to be running smoothly,
at least before a full gc.
2. It only runs on "Server" VMs now. My last JPRT test shows it failing
on all c1 VMs and succeeding on all c2 VMs.
Is that the only way to determine if a server VM is being used? The name and
whether it includes "Server" seems to be implementation specific.
Otherwise looks fine to me.
--Sean
I just finished a new JPRT test, all builds and tests pass on supported
platforms.
Thanks
Max
On 10/10/2011 10:59 PM, Weijun Wang wrote:
I'm now running JPRT tests on this fix.
Unfortunately, for the 6 finished tests, I've already seen linux-i586
and solaris-i586 (both with c1 VM) failed on the new test with
java.lang.OutOfMemoryError: Java heap space
I guess our DER parsing codes are using too many memory. Maybe multiple
copies of huge byte array here and there. In the short term, I'll see if
I can rewrite the test with othervm and a proper -Xmx option.
Hopefully customer dealing with these huge CRLs always use c2 VM with
lots of memory.
-Max
On 10/10/2011 8:19 PM, Xuelei Fan wrote:
Right! Then fine to me.
Thanks,
Xuelei
On 10/11/2011 11:13 AM, Weijun Wang wrote:
0xff will be 255, -1 means no byte to read, EOF.
On Oct 10, 2011, at 7:15 PM, Xuelei Fan<xuelei....@oracle.com> wrote:
I'm not sure why the latest byte cannot be 0xFF? What about if my
content length is 256? For example:
677 if (lowByte == -1) {
678 throw new IOException("Incomplete BER/DER length info");
679 }
Otherwise, looks fine to me.
Xuelei
On 10/11/2011 9:05 AM, Weijun Wang wrote:
Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/
Basically, we're now accepting X.509 block of 4-octets length. For
simplicity, the highest byte must be<= 127, so that the length can be
expressed with a 32-bit int.
Thanks
Max
-------- Original Message --------
*Change Request ID*: 7099399
*Synopsis*: cannot deal with CRL file larger than 16MB
Product: java
Category: java
Subcategory: classes_security
Type: Defect
=== *Description*
============================================================
The X.509 impl of CertificateFactory only parses X.509 blocks smaller
than 16MB, i.e. when the length can be encoded in 3 octets. Now we
have
a customer whose CRL file is as big as 30MB.
