Skip to main content

What is java_impl.exe?

22 replies [Last post]
jansan
Offline
Joined: 2005-02-24

I just noticed that there are two java processed running now, java.exe and java_impl.exe. java.exe used only about 800 kBytes, while java_impl.exe seems to be the former java.exe process, consuming more than 25 MBytes. I think this is new in Mustang b71 (but I am not sure). Can someone explain what this change means? Is this a step towards a shared VM?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jddarcy
Offline
Joined: 2004-11-02

> The function exists in Windows XP SP1 or greater,
> Windows XP x64, Windows Vista and Windows Server
> 2003. Will JDK 1.6 support any Windows version lower
> than that?

The current supported configurations list
http://java.sun.com/javase/webnotes/6/install/system-configurations.html
includes Windows 2000. We also try not to gratuitously break Windows 98, which some people still run.

cowwoc
Offline
Joined: 2003-08-24

Bugid 6382014 which you mentioned is not visible on BugParade. How do you guys plan on fixing this so it both works under vc7 and without mini-launchers? Seems like a lot of work when all you're really trying to do is add /bin to the PATH of the system. I assume that would be easier than copying files into \windows\system32 which clutters it.

The downside of using PATH, however, is that there might be a fundamental mismatch between what JRE executes by default (due to PATH) and what is actually supposed to be executing according to the registry and/or installer. Anyway, I'm curious how you guys solved it ;)

jddarcy
Offline
Joined: 2004-11-02

> Bugid 6382014 which you mentioned is not visible on
> BugParade. How do you guys plan on fixing this so it
> both works under vc7 and without mini-launchers?

The basic solution is that the launcher derived binaries in question will be statically linked with the required library. This was not pursued initially due to possible complications from statically and dynamically linking with the same library, which is what will be happening after the fix.

cowwoc
Offline
Joined: 2003-08-24

Statically and dynamically linking against the same library?! Eek! I strongly suspect you will run into weird crashes at runtime.

Wouldn't it be safer to just use PATH approach instead? After all, that's what other native applications do... What does Microsoft do with .NET?

jddarcy
Offline
Joined: 2004-11-02

> Statically and dynamically linking against the same
> library?! Eek! I strongly suspect you will run into
> weird crashes at runtime.

We were initially hesitant, but after thorough investigation we're confident the dual linking should "just work." The problems arise if you try to pass data between the static and dynamic incarnations of the library, which we don't do.

> Wouldn't it be safer to just use PATH approach
> instead? After all, that's what other native
> applications do... What does Microsoft do with .NET?

For completeness, we considered modifying the path, but that would not play well with our existing JDK installer and registry policies so it was not a viable alternative.

eburnette
Offline
Joined: 2005-04-17

If java.exe is in the same directory as the java dll then you don't need to put it in the path; the load library will pick up the correct dll. Why wouldn't that work?

mthornton
Offline
Joined: 2003-06-10

The issue is the copy of java.exe which is placed in the Windows system32 directory. There are no java dlls in the same place.
This copy of java.exe is there so that you can conveniently just type java on the command line without having to extend the system or user path (which for many of us is ridiculously long already).

rogerhernandez
Offline
Joined: 2005-02-23

Why don't they just use the Windows SDK function made to fix that problem?

BOOL SetDllDirectory(LPCTSTR lpPathName);

Remarks
The SetDllDirectory function affects all subsequent calls to the LoadLibrary and LoadLibraryEx functions. After calling SetDllDirectory, the DLL search path is:

1. The directory from which the application loaded.
2. The directory specified by the lpPathName parameter.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is System32.
4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable.

To revert to the default search path used by LoadLibrary and LoadLibraryEx, call SetDllDirectory with NULL.

To compile an application that uses this function, define _WIN32_WINNT as 0x0502 or later. For more information, see Using the Windows Headers.

mthornton
Offline
Joined: 2003-06-10

> To compile an application that uses this function,
> define _WIN32_WINNT as 0x0502 or later. For more

Perhaps because they still support versions of Windows that do not have that function.

rogerhernandez
Offline
Joined: 2005-02-23

The function exists in Windows XP SP1 or greater, Windows XP x64, Windows Vista and Windows Server 2003. Will JDK 1.6 support any Windows version lower than that?

cowwoc
Offline
Joined: 2003-08-24

That's a good point, I totally forgot about that approach :)

The good news is that you don't even need to use that function to achieve the desired behavior. My code has the exact same problem and instead of using SetDllDirectory() I simply use getenv() and putenv() to grab the PATH variable, prefix the DLL path into it, then save the changes. Then on shutdown of the application I undo this change. Though in retrospect I don't even think you need to undo the change on exit, it might get automatically undone when the process exits.

Anyway, would Sun consider using this approach?

jek3
Offline
Joined: 2006-02-13

With respect to the proposal of setting %PATH% in the environment...

First, is this written down as part of the MSDN specification (if so where) or just something which has been found to work? We try to code to the specification. I'm suspicious, because this definitely won't work on Solaris (ld.so reads the environment at start-up and not at every library load).

Second, %PATH% is read after all the hardwired places are checked. This means that if another copy of the library in question is found in one of those hardwired places, it will be used rather than the one we expect to be used. Its not exactly clear why Microsoft changed the "best practice" usage of these libraries with the v7 tools, but it appears to be an attempt to minimize "dll hell" by not sharing libraries (I guess memory load no longer matters). In any case, this approach would revert the search characteristics to pretty much what they were before, circumventing Microsoft's apparent intent.

A couple BTW remarks:

1) This has been "fixed" (farewell java_impl.exe) in b75.

1a) There is a little bug which slipped through the initial testing that "v" in the javaws console doesn't work. This is expected to be fixed in b76.

2) Several bugs were filed on this. The primary one used to fix it was 6382014. It should have many, many dups.

3) I'm jek3 from California. My earlier posts show as from Edwin57 from "Eupen Belgium". Anybody know how to fix this?

cowwoc
Offline
Joined: 2003-08-24

1) I just noticed that the specification of loadLibrary() lets you specify a fully-qualified path to the DLL. You can use this and be absolutely sure the right DLL file is being loaded.

2) The specification for loadLibrary() says "[...] Doing this allows private dynamic-link library (DLL) files associated with a process to be found without adding the process's installed directory to the PATH environment variable." which seems to imply that PATH is read dynamically even after the process is launched. Besides which, from practical experience this behavior has held for every single version of Windows I have tested with (Win2k and WinXP for sure). The specification for SetDllDirectory() lists the full-fledged search path for DLLs. Note that there is no mention of the fact that PATH may not be changed after process startup *and* note that if you specify a fully-qualified path, it gets used before any of the hard-wired paths.

As far as I can tell, the simplest and most portable solution is to pass a fully-qualified path to the DLL (or just launching java.exe from the jre/bin directory to begin with). It just scares me a bit to think that when I run "java" in the command-line I'm not really running the executable I think I am (the one found in the jre directory). Sorry for beating this point to death :) but it is the way I feel.

Gili

mthornton
Offline
Joined: 2003-06-10

I wonder if the Windows "App Paths" mechanism could be useful in solving in eliminating java_impl.exe

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc...

cowwoc
Offline
Joined: 2003-08-24

I just wanted to note another problem with the c:\windows\system32\java.exe approach. When I try rebuilding Hibernate using build.bat that comes with it, it invokes the command-line:

java -cp "lib/ant-launcher-1.6.5.jar" org.apache.tools.ant.launch.Launcher -lib lib %1 %2 %3 %4 %5

Now, by default "java" resolves to c:\windows\system32\java.exe

When I run build.bat I get:

C:\Program Files\hibernate\build.xml:218: Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK

Now, upon changing "java" in the script to "C:\Program Files\Java\jdk1.5.0_06\bin\java" the problem goes away.

This is yet another reason we really should be running the real java.exe file, not a fake one in c:\windows\system32, because it causes a whole bunch of unforseen problems.

(This is likely a bug in their batch file or AntLauncher, but I thought it was worth mentioning)

opinali
Offline
Joined: 2003-06-17

Add me to the list of people waiting anxiously for this artifact to vanish in b75. It's a problem not only for development, but everywhere. Java would become the laughing stock of programming languages if end users and admins noticed that it requires two OS processes per application -- this screws so many things up that can't even be counted. Not even MVM functionality would justify that. I appreciate, though, that you are wrestling with these DLL linking issues in Windows. Perhaps the solution is moving to JNode ;-)

spdenne
Offline
Joined: 2006-02-15

Another annoying impact that I'm seeing is with eclipse. When terminating a java app, the java.exe is terminated, and the java_impl.exe just continues running un-parented.

jansan
Offline
Joined: 2005-02-24

I agree to spdenne that this has a negative impact for development. In IntelliJ the application also does not exit when I try to shut it down from within the IDE. In cases of infitite loops (just ran into one) and other cases when the app cannot be shut down through a close button this can be very annoying, because I have to use the task manager.

Erwin57
Offline
Joined: 2006-02-17

The java_impl.exe process is an artifact of the JDK trying to comply with Window's current linking best practices (bug 6282039). For the builds with java_impl.exe, java.exe is a "mini-launcher" which "execs" the real Java implementation binary. The term "execs" is in quotes because Windows doesn't support a true unix-style exec system call; those semantics can only be approximated and its much more like a POSIX spawn(). In any case, we've determined that the mini-launcher solution to the underlying problem is suboptimal and java_impl.exe should be gone within a few builds; we are currently targeting build 75. Bugid 6382014 is being used to make the change which should eliminate java_impl.exe (and friends).

Attempting to attach a debugger to java.exe will probably be rather unsatisfying. If you attach to java_impl.exe, everything should be as it was before and should be again.

Erwin57
Offline
Joined: 2006-02-17

Replying to myself,... not a good sign.

This is only on Windows (including x64). This probably accounts for why not everyone is seeing it.

It also first appeared in b68 at which time an internal "merge error" resulted in it not accomplishing its intended purpose. b71 works as intended, but as above, is being re-implemented due to the impact of known side effects.

trembovetski
Offline
Joined: 2003-12-31

Yeah, I've noticed this java_impl as well. I'll try to find out that's up with this.

Dmitri
Java2D Team

alexlamsl
Offline
Joined: 2004-09-02

sounds like so - I don't get that in b70 ;)