On Oct 12, 2011, at 7:19 AM, Sean Mullan <[email protected]> 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. Yes it does not look reliable. In fact, this requirement of a server VM is only related to the max heap size. I'm about to do some measurement today. Hopefully I can add -Xmx??m in the @run line and remove the server VM check. That will need another webrev. -Max > > 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<[email protected]> 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. >>>>>>> >>>>>> >>>>
