Java creates DAD devices

[Fletcher Curry]

I'm running Java 1.5.0-1.p1 on OpenVMS V7.3-2. Every time I call the java.io.File.listRoots() method, three new DAD device entries are created. Here's an excerpt from my SHOW DEVICE DAD display:

Device Device Error
Name Status Count
DAD0: Online 0
DAD1: Online 0
DAD2: Online 0

. . .

DAD655: Online 0
DAD656: Online 0
DAD657: Online 0

These entries do not go away when I shut down the VM with java.lang.System.exit(), so they accumulate over time. This behavior is the same using the Fast and Classic VMs. Each of these devices is apparently using some nonpaged dynamic memory, because once I have several thousand of them, nonpaged dynamic memory is exhausted and system performance degrades horribly.

How can I prevent Java from creating these? Barring that, how can I get rid of them myself without rebooting?

Thanks.

- Fletcher

[John Gillings]

Fletcher,

That's very odd! DAD devices are normally associated with InfoServers (they're InfoServer mapped disks). No idea what interest Java may have in an ancient storage server protocol.

Do you know if you're running LAD or LAST protocols? See SYS$STARTUP:ESS$LAD_STARTUP and ESS$LAST_STARTUP?

You may be able to UNBIND the devices, try:

$ MCR ESS$LADCP UNBIND DAD655:

If you're not using LAD or LAST, try removing them from your startup. Check if DAD0 exists after a reboot. I think there was once a bug where a $ASSIGN to DAD0: would generate a spurious DAD device. Stop DAD0 from being created and you should get rid of the problem.

As a workaround, write a procedure that uses F$DEVICE to scan for DAD devices and UNBIND them. Run it often enough to keep the PAGEDYN load to an acceptable level.

[John Gillings]

Fletcher,

After some more experiments...

Look for ESS$STARTUP in your startup procedures. That's what creates DAD0, and starts up LAD and LAST.

It's easy to show that $ASSIGN against DAD0 creates a DAD device. I now think this is by design, rather than a bug. It's likely to be the mechanism used to create devices from the template.

Try

$ OPEN TEST DAD0:

This will fail with RMS-E-DNR, but will have created a new DAD device. So, I guess your Java method is scanning devices and opening channels? It should probably be checking DAD devices, after all, they're usually disks, but should be skipping DAD0.


$ MCR ESS$LADCP UNBIND DADnnn

will delete the device, but it's a good idea to make sure no one's using it!

I've attached a procedure that takes a fairly cautious approach. It uses F$DEVICE to scan for DAD devices. For each one it checks the operation count, reference count and owner PID. If all are null, the device is assumed to be unused and is deleted.

I've found a few devices on one system that have small operation counts (maximum 3). I'm assuming these are also junk, but my procedure won't touch them. You can decide how to handle your own case.

If you're not using LAD and LAST (and I'd guess it's highly unlikely that you are!), removing ESS$STARTUP from your startup procedure will solve the problem permanently after the next reboot.

[Fletcher Curry]

John -

Thanks.

The UNBIND command worked like a charm. I like your cautious procedure much better that the brute force one I just ran that deleted all of the DADs above DAD0 without checking to see if they were in use. I'll use yours next time. My memory numbers look better after the UNBINDs. We're looking into whether we can disable ESS$STARTUP. I'll bet we can.

Still, it would be good if Java would avoid opening DAD0.

- Fletcher

[Fletcher Curry]

Curse my scroll-wheel! That 3 was supposed to be a 10.

[John Gillings]

Fletcher,

I've confirmed Java is calling sys$device_scan looking for disk devices and calling the CRTL function "access" to see if they're readable. That results in one or more $ASSIGNs against DAD0: which generate the spurious devices.

There are a few ways to fix this - it's a matter of working out the most appropriate place.

This would need a case logged against a service contract to make certain it gets fixed.

[Rick Dyson]

Wow! I used to manually clean those out and no matter who I asked, no one seemed to know what was creating the DADn: devcies. I was actually using InfoServers but then retired them last year. So now I don't run the ESS$Startup and I don't get them anymore. I forgot about it until I saw this! I don't use JAVA much at all directly, but it was installed and I guess some stuff like WEBES, etc. does use it.

Sorry, can't help fix it but wanted to say I too had the problems for a couple years. I don't remember how long ago, but I want to say even as far back as 2004.

Rick

rick

[John Gillings · Accepted solution]

Rick, Fletcher,

Java engineering has modified the device scan loop in java.io.File.listRoots It now checks that a device is mounted before attempting to access it. That will skip over DAD0, and should pulg the leak.

Incindentally, I'd guess that if this refers to performance of listRoots:

>system performance degrades horribly.

it's probably not because of NPAGEDYN depletion, but rather because the device scan loops over all those DAD devices, checking each one for accessibility. As the list gets longer, the scan time increases.

Although the fix is checked in, since the issue wasn't raised by a contract customer, it won't automatically be released as a patch. If you want/need the patch before the next release, please log a case with your local customer support centre.

[Fletcher Curry]

John -

Thanks for pursuing this. We have asked out client to log a case.

Now that you mention it, our worst delays were during the class load in which listRoots was used, so scanning the device list probably was the problem.

- Fletcher