The issue is that Oracle is being confusing abut the JRE.
The OSX JRE, which is what you downloaded, does not update /usr/bin/java it just installs itself to /Library/Java/JavaVirtualMachines/
You can either use the path to the java binary beneath that or instead install the JDK from this page which does update /usr/bin/java
@RichTrouton's answer might be correct on what Chrome uses i.e. a 32 bit JRE but this answer explained /usr/bin/java issues. Note that the simple Oracle JRE does not update /usr/bin/java and I think Apple's later installs do not touch this either. Your browser does not use /usr/bin/java but directly looks in /System or /Library
As you may know Google Chrome runs as a multi-process application. You have your initial "Google Chrome" process that manages the UI and plays "host" to a number of other processes. A new "renderer" process is created for each tab you open in Chrome, a "plugin" process for each extension you install, and there is a separate "GPU" process for the code that talks to the system's GPU. Each of these other processes appears in Activity Monitor as a "Google Chrome Helper" process.
To make Chrome more secure, the renderer processes run in a sandbox. They are only able to talk to the network through the host process and can only talk to specific files (for example, fonts and ColorSync profiles). They are also prevented from talking to other processes in the system, which is what causes these log messages. The renderer processes are trying to talk to the launchserviced and windowservice processes, but being prevented from doing that because of their sandbox.
This bug was resolved by a software engineer on Google's Chrome Security team with a commit in February 2014. Removing this one line of code resolved the problem.
[NSApplication sharedApplication];
Amongst other things, calling the sharedApplication method opens a connection between an application and OS X's WindowServer, which you can see failing in the CGSLookupServerRootPort error.
The intention was for Chrome to call this method to "warm up" certain resources before enabling the sandbox; gaining access to certain files, processes or network resources before the sandbox restrictions fell in place. However it seems that at some point this attempt started failing, resulting in these errors in the log. My guess is that Apple considered this "warming up" an attempt to cheat the sandbox and started clamping down on it.
If I'm reading correctly this change reached the stable release channel with an update of Google Chrome to 34.0.1847.131 in April 2014.
Interestingly the Chrome team had been discussing removing these calls to the sharedApplication method back in October 2013 and even discussed removing Cocoa entirely from the renderer processes as a goal back in 2009.
On a related note, Apple released a security fix in April 2014 to resolve a bug where "WindowServer sessions could be created by sandboxed applications."
Best Answer
Since v39, Chrome is 64-bit.
At the time of writing, there is no 64-bit version of Google Chrome for Mac.You should be able to run your Java content in Safari for now, since Safari is 64-bit and can run Java 7.