On 6/03/2015 4:10 AM, Jeremy Manson wrote:
Martin points out that getenv on Windows isn't portable (which is to say, it doesn't work on WindowsRT). Do we care? If so, then I'll have os::getenv do an allocation on Windows, and have it return a unique pointer like thing. (Of course, I have no way of testing that).
Many of the win32 APIs we use in the VM are not available in WindowsRT. So I don't think that is an issue.
David -----
Jeremy On Wed, Mar 4, 2015 at 5:12 PM, David Holmes <david.hol...@oracle.com <mailto:david.hol...@oracle.com>> wrote: On 5/03/2015 10:07 AM, Jeremy Manson wrote: I'm happy to s/os::getenv/getenv/g if we know it works on Windows. I assumed that there was some safety / security reason for requiring the copying - otherwise, why does this interface exist at all? I don't know. Someone else (perhaps on hotspot list rather than serviceability) may, but I'd have to do a bit of archaeology to find out. If everyone's happy about this, I'll go ahead and file a bug / send in a patch, with the understanding that someone else has to test on non-Linux platforms... Sure. Do the patch and I'll run it through JPRT. If you need testing other than Solaris and Windows then others will need to step up. :) Cheers, David Jeremy On Wed, Mar 4, 2015 at 3:45 PM, David Holmes <david.hol...@oracle.com <mailto:david.hol...@oracle.com> <mailto:david.holmes@oracle.__com <mailto:david.hol...@oracle.com>>> wrote: Hi Jeremy, On 5/03/2015 6:14 AM, Jeremy Manson wrote: Hey folks, We had a request internally to make it so that JAVA_TOOL_OPTIONS could accept something longer than 1024 characters. See: Arguments::parse_options_____environment_variable(const char* name, SysClassPath* scp_p, bool* scp_assembly_required_p) in http://hg.openjdk.java.net/____jdk9/jdk9/hotspot/file/____27f0413cbea3/src/share/vm/____runtime/arguments.cpp <http://hg.openjdk.java.net/__jdk9/jdk9/hotspot/file/__27f0413cbea3/src/share/vm/__runtime/arguments.cpp> <http://hg.openjdk.java.net/__jdk9/jdk9/hotspot/file/__27f0413cbea3/src/share/vm/__runtime/arguments.cpp <http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/27f0413cbea3/src/share/vm/runtime/arguments.cpp>> Would you folks be amenable to a refactoring so that getenv returns a newly allocated array with the contents of the envvar, which the caller has to delete? I think this gets used too early in the VM startup to use the VM's allocation routines (ie with NMT support) - not 100% sure though. But I think I have to agree with Martin and wonder why we have this copying interface around getenv, rather than using the result of getenv directly? Any code that really wants to modify the returned value can copy it for themselves. That would alleviate the hard wired limits. getenv is available on Windows too. David Jeremy
