Re: AES GCM slow

[Florian Weimer]

On 01/27/2014 05:46 PM, Michael StJohns wrote:

GCM uses a GF2 multiply as part of the integrity calculation.  That
operation is pretty expensive.  My guess is that if the code was
profiled, you'd find a lot of time being spent in
com.sun.crypto.provider.GHASH.


I ran into this and posted a fix: 



The AES-GCM implementation still conses a lot in unrelated parts of the 
code, but that's a separate fix.


--
Florian Weimer / Red Hat Product Security

Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

[Florian Weimer]

On 02/28/2014 03:40 PM, Chris Hegarty wrote:

Either:
  1) FD_SETSIZE needs to be set to a larger value, but what value, the
 kernel limit, or other? This is wasteful for most typical apps that
 don't use large numbers of file descriptors. Or,
  2) If fd is greater than 1024, then an appropriate amount of memory
 could be allocated and cast to an fd_set. The FD_SET macro will
 write past FD_SETSIZE.


3) use poll

Why do we have to use select here?

--
Florian Weimer / Red Hat Product Security

Re: sun.net.www.protocol.https.HttpsURLConnectionImpl doesn't equal to self

[Michael McMahon]

I'll file a bug for this Stanimir. Thanks for reporting it.
Should be able to fix it in JDK 9 fairly promptly
and we'll see about back porting it then.

- Michael.

On 18/08/14 15:04, Stanimir Simeonoff wrote:

Hi,

As the title says there is a major bug with HttpsURLConnection as it breaks
the contract of equals. So the instance  cannot be contained (mostly
removed) in any collection reliably. (Concurrent)HashMap has a provision to
test equality by reference prior calling equals, though.
Finding the bug in production is quite a ride as the http variant doesn't
exhibit the problem.

Here is a simple test case.

public static void main(String[] args) throws Throwable{
  URLConnection c = new URL("https://oracle.com";).openConnection();
  System.out.println(c.getClass().getName()+" equals self: "
+c.equals(c));
  c.getInputStream().close();
  System.out.println(c.getClass().getName()+" equals self: "
+c.equals(c));
}


The culprit is in HttpsURLConnectionImpl.equals that blindly calls
delagate.equals:

 public boolean equals(Object obj) {
 return delegate.equals(obj);
 }

It should be changed to:

 public boolean equals(Object obj) {
 return this==obj || (obj instanceof HttpsURLConnectionImpl) &&
delegate.equals( ((HttpsURLConnectionImpl)obj).delegate );
 }


The class has some other issue that involves declaring "finalize" method to
simply call delegate's dispose. The finalize method is unneeded and just
creates unnecessary link in the finalization queue + Finalizer object.

Thanks
Stanimir

Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

[Christos Zoulas]

On Aug 18,  5:10pm, fwei...@redhat.com (Florian Weimer) wrote:
-- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

| On 02/28/2014 03:40 PM, Chris Hegarty wrote:
| > Either:
| >   1) FD_SETSIZE needs to be set to a larger value, but what value, the
| >  kernel limit, or other? This is wasteful for most typical apps that
| >  don't use large numbers of file descriptors. Or,
| >   2) If fd is greater than 1024, then an appropriate amount of memory
| >  could be allocated and cast to an fd_set. The FD_SET macro will
| >  write past FD_SETSIZE.
| 
| 3) use poll
| 
| Why do we have to use select here?

Because poll is still broken on UDP sockets.

christos

Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

[Florian Weimer]

On 08/18/2014 05:36 PM, Christos Zoulas wrote:

On Aug 18,  5:10pm, fwei...@redhat.com (Florian Weimer) wrote:
-- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

| On 02/28/2014 03:40 PM, Chris Hegarty wrote:
| > Either:
| >   1) FD_SETSIZE needs to be set to a larger value, but what value, the
| >  kernel limit, or other? This is wasteful for most typical apps that
| >  don't use large numbers of file descriptors. Or,
| >   2) If fd is greater than 1024, then an appropriate amount of memory
| >  could be allocated and cast to an fd_set. The FD_SET macro will
| >  write past FD_SETSIZE.
|
| 3) use poll
|
| Why do we have to use select here?

Because poll is still broken on UDP sockets.


Ugh.  Can you provide details, such as affected platforms?  Thanks.

--
Florian Weimer / Red Hat Product Security

Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

[Christos Zoulas]

On Aug 18,  5:42pm, fwei...@redhat.com (Florian Weimer) wrote:
-- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

| On 08/18/2014 05:36 PM, Christos Zoulas wrote:
| > On Aug 18,  5:10pm, fwei...@redhat.com (Florian Weimer) wrote:
| > -- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx
| >
| > | On 02/28/2014 03:40 PM, Chris Hegarty wrote:
| > | > Either:
| > | >   1) FD_SETSIZE needs to be set to a larger value, but what value, the
| > | >  kernel limit, or other? This is wasteful for most typical apps that
| > | >  don't use large numbers of file descriptors. Or,
| > | >   2) If fd is greater than 1024, then an appropriate amount of memory
| > | >  could be allocated and cast to an fd_set. The FD_SET macro will
| > | >  write past FD_SETSIZE.
| > |
| > | 3) use poll
| > |
| > | Why do we have to use select here?
| >
| > Because poll is still broken on UDP sockets.
| 
| Ugh.  Can you provide details, such as affected platforms?  Thanks.

Just macos/x. Empty UDP packets don't make poll fire.

https://bugs.openjdk.java.net/browse/JDK-7131399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

christos