JDK-7080966 : JSObject could be released prematurely on server VM
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-08-19
  • Updated: 2011-09-22
  • Resolved: 2011-08-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
7u2 b03Fixed 8Fixed
When running sample at

The following exception is observed, 

JSException - "Attempt to reference unknown or already-released JavaScript object; may not pass JSObjects between applets directly"

SUGGESTED FIX The server side should implement reference counting to ensure the get/release are done atomically instead of client side, which will subject to race condition with IPC latency.

EVALUATION Fundamentally, we have a design flaw in the reference tracking on browser object, and it is revealed now with message deadlock fix for FX. The client side JSObject is tracked based on JVM GC. Each call to getJSObject() or getWebContext() actually return a new instance of JSObject. That is, each instance can be GCed. We try to maintain a reference counting system based on the native handle and ask server to release the object when the reference count reduced to 0. On the server side, the reference count is done by browser, we simply tracking the native handle. Whenever a native handle is passed to the client side, we register it, and unregister it when client VM asked to release the object. The bug is, same native handle can be treated as different object on the client side, and a race condition could cause the object to be released as the reference count down to 0, and noted the race condition could involve latency for getting back from server VM. When a LiveConnect call is made to the server side, we check if the native handle is registered, and throw the exception we observed if it is not. The FX message deadlock fix, allows FX application thread run nested message loop while waiting for the response from the browser(more precisely, server VM). Assuming we call getWindowContext() and prepared to LiveConnect call. When waiting for that response, in the nested message handler, somehow we release the JSObject obtained earlier thus could cause release on the server side. Therefore, following call to use the newly obtained JSObject will cause that exception because on the server side, the native handle had been unregistered. However, this is only a faulty alarm as the native object still hold valid in the browser.