Looks fine to me. Xuelei
On 10/13/2011 3:12 AM, Weijun Wang wrote: > 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. >>>>>>>> >>>>>>> >>>>>
