From dmitry.samersoff at oracle.com Tue Apr 1 12:50:53 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 01 Apr 2014 16:50:53 +0400 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> Message-ID: <533AB62D.1010501@oracle.com> Goetz, Push done. Let it bakes for some times in JDK9 (at least two nightlies) than I'll push it to 8u20 -Dmitry On 2014-03-27 23:52, Lindenmaier, Goetz wrote: > Thanks Dmitry and Vladimir! > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, March 27, 2014 8:18 PM > To: Dmitry Samersoff; Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() > > Thank you, Dmitry > > We need to backport it into 8u20 too. > > Regards, > Vladimir > > On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> I can push it to RT next week. >> >> -Dmitry >> >> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Looks good for me! >>> >>> +1. >>> >>> Dmitry, >>> >>> Do you want me to push it into Comp repo or you will do it into RT repo? >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>> Hi Dmitry, >>>>> >>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>> I had a look at set_boot_path(). That will never return false, >>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>> In addition it would be wrong to return, there should be a >>>>> call to vm_exit_... >>>>> So I removed the test and return statement. >>>>> I added the other missing FREEs. >>>>> >>>>> I also implemented your proposal with only one sprintf >>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>> to get it more similar. Solaris seems too different to >>>>> adapt to that scheme. >>>>> >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>> ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Goetz, >>>>> >>>>> Thank you for doing it - code is much cleaner now. >>>>> >>>>> os_aix.cpp: >>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>> >>>>> os_bsd.cpp: >>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>> >>>>> ll.407 sprintf could be moved to ll.420 under else >>>>> >>>>> >>>>> ll.497 (and below) a trick like one below: >>>>> >>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>> char *v_colon = ":"; >>>>> >>>>> if (l != NULL || v != NULL) { >>>>> >>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>> >>>>> t = (char *) ... /* allocate memory for all strings */ >>>>> >>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, ld_library_path); >>>>> if (ld_library_path != buf){ ... /* free ld_library_path */ } >>>>> ld_library_path = t; >>>>> } >>>>> >>>>> might be useful to assemble the path in one shot, >>>>> without extra copying >>>>> >>>>> >>>>> ll.520 As you appending constant value ":.", you can just >>>>> take it into account at ll. 495 >>>>> >>>>> >>>>> os_linux.cpp: >>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>> >>>>> os_solaris.cpp: >>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>> >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> please have a look at this new webrev: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>> >>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>> the missing parts in here, below. >>>>>> >>>>>> Avoiding big stack allocations I wanted to remove the buf[MAXPATHLEN] >>>>>> at the beginning of the function, too. That's why I said I can't >>>>>> get along >>>>>> with a single allocation. strlen(v) is only known later. >>>>>> >>>>>> I could redesign the whole code, computing sizes first, and then >>>>>> doing a single allocation, but I think that doesn't help the >>>>>> readability of the code. >>>>>> >>>>>> So now I compute the max size of all buffers I can estimate at the >>>>>> beginning >>>>>> and do a single allocation for them. >>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> Goetz, >>>>>> >>>>>>> The allocation in 556 must know about the length of the >>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>> >>>>>> You can use >>>>>> >>>>>> MAX( >>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + sizeof(ENDORSED_DIR) >>>>>> ) >>>>>> >>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>> >>>>>> But I'm fine with two different allocations. >>>>>> >>>>>> Thank you for addressing other concerns. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> see my comments inline. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>> malloc() in init_system_properties_values() >>>>>>>> >>>>>>>> Goetz, >>>>>>>> >>>>>>>> os_aix.cpp: 565 >>>>>>>> >>>>>>>> It might be better to allocate one buffer that satisfy all three >>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>> I need at least two allocations. The first one has a statically >>>>>>> known size. At >>>>>>> least more or less, as I know there will be only one path of >>>>>>> unknown size in the buffer. >>>>>>> The allocation in 556 must know about the length of the >>>>>>> getenv("LIBPATH") result, >>>>>>> which may contain several paths. >>>>>>> Also, in the other files, paths are concatenated, so at least two >>>>>>> buffers are needed. >>>>>>> >>>>>>>> os_bsd.cpp: 350 >>>>>>>> >>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, it makes >>>>>>>> code much more readable. >>>>>>> I'll fix this. >>>>>>> >>>>>>>> os_bsd.cpp: 485 >>>>>>>> >>>>>>>> you replace malloc to on-stack allocation of more than 4096 bytes. I >>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>> > see also comments to os_aix above - you can allocate large enough >>>>>>>> buffer once and than reuse it. >>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in the >>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>> The space required by the existing buf can be reused by the C >>>>>>> compiler. >>>>>>> >>>>>>> But I'll fix that and only use allocated memory. >>>>>>> I'll remove the buf that was already there and replace all spaces >>>>>>> I can estimate by MAXPATHLEN + some offset by a single, allocated >>>>>>> buffer. >>>>>>> I'll do this the same on all four platforms. >>>>>>> >>>>>>>> os_linux.cpp: 434 >>>>>>>> the same comments as above. >>>>>>>> >>>>>>>> os_solaris.cpp: 728 >>>>>>>> >>>>>>>> As soon as you doing cleanup, I would love to have this code >>>>>>>> changed >>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>> respect >>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>> variables. >>>>>>>> >>>>>>>> Could you change it to something like: >>>>>>>> Dl_serinfo info_sz, *info; >>>>>>> Yes, I'll fix that. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == -1) { >>>>>> ... >>>>>> >>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>> mtInternal); >>>>>> ... >>>>>> >>>>>> os_solaris.cpp: 829 >>>>>> The same comment about on-stack allocation as for os_bsd.cpp >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review and test this change. I please need a sponsor. >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>> >>>>>>> This change addresses the implementation of >>>>>>> init_system_properties_values >>>>>>> on aix, linux, solaris and bsd. >>>>>>> In init_system_properties_values a macro was defined mapping malloc to >>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful allocation >>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>> pointers as >>>>>>> allocated with real malloc, i.e., there were checks for NULL and >>>>>>> calls to free(). >>>>>>> >>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>> removes >>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>> local array where >>>>>>> possible. >>>>>>> >>>>>>> The allocated memory is passed to calls that end up at >>>>>>> SystemProperty::set_value(). >>>>>>> set_value copies the strings passed. Thus the memory allocated in >>>>>>> init_system_properties_values must be freed after these calls. >>>>>>> Most of these >>>>>>> frees were missing. >>>>>>> >>>>>>> This change adds the missing frees. >>>>>>> >>>>>>> Testing this change I ran into a warning in ppc code which I fixed, >>>>>>> too. >>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From goetz.lindenmaier at sap.com Tue Apr 1 12:53:47 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Apr 2014 12:53:47 +0000 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <533AB62D.1010501@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAC14C@DEWDFEMB12A.global.corp.sap> Hi Dmitry, thanks a lot for your help. I tested the webrev with 'const' on linux ppc and aix, works fine! Best regards, Goetz. -----Original Message----- From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] Sent: Dienstag, 1. April 2014 14:51 To: Lindenmaier, Goetz; 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() Goetz, Push done. Let it bakes for some times in JDK9 (at least two nightlies) than I'll push it to 8u20 -Dmitry On 2014-03-27 23:52, Lindenmaier, Goetz wrote: > Thanks Dmitry and Vladimir! > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, March 27, 2014 8:18 PM > To: Dmitry Samersoff; Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() > > Thank you, Dmitry > > We need to backport it into 8u20 too. > > Regards, > Vladimir > > On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> I can push it to RT next week. >> >> -Dmitry >> >> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Looks good for me! >>> >>> +1. >>> >>> Dmitry, >>> >>> Do you want me to push it into Comp repo or you will do it into RT repo? >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>> Hi Dmitry, >>>>> >>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>> I had a look at set_boot_path(). That will never return false, >>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>> In addition it would be wrong to return, there should be a >>>>> call to vm_exit_... >>>>> So I removed the test and return statement. >>>>> I added the other missing FREEs. >>>>> >>>>> I also implemented your proposal with only one sprintf >>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>> to get it more similar. Solaris seems too different to >>>>> adapt to that scheme. >>>>> >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>> ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Goetz, >>>>> >>>>> Thank you for doing it - code is much cleaner now. >>>>> >>>>> os_aix.cpp: >>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>> >>>>> os_bsd.cpp: >>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>> >>>>> ll.407 sprintf could be moved to ll.420 under else >>>>> >>>>> >>>>> ll.497 (and below) a trick like one below: >>>>> >>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>> char *v_colon = ":"; >>>>> >>>>> if (l != NULL || v != NULL) { >>>>> >>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>> >>>>> t = (char *) ... /* allocate memory for all strings */ >>>>> >>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, ld_library_path); >>>>> if (ld_library_path != buf){ ... /* free ld_library_path */ } >>>>> ld_library_path = t; >>>>> } >>>>> >>>>> might be useful to assemble the path in one shot, >>>>> without extra copying >>>>> >>>>> >>>>> ll.520 As you appending constant value ":.", you can just >>>>> take it into account at ll. 495 >>>>> >>>>> >>>>> os_linux.cpp: >>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>> >>>>> os_solaris.cpp: >>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>> >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> please have a look at this new webrev: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>> >>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>> the missing parts in here, below. >>>>>> >>>>>> Avoiding big stack allocations I wanted to remove the buf[MAXPATHLEN] >>>>>> at the beginning of the function, too. That's why I said I can't >>>>>> get along >>>>>> with a single allocation. strlen(v) is only known later. >>>>>> >>>>>> I could redesign the whole code, computing sizes first, and then >>>>>> doing a single allocation, but I think that doesn't help the >>>>>> readability of the code. >>>>>> >>>>>> So now I compute the max size of all buffers I can estimate at the >>>>>> beginning >>>>>> and do a single allocation for them. >>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> Goetz, >>>>>> >>>>>>> The allocation in 556 must know about the length of the >>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>> >>>>>> You can use >>>>>> >>>>>> MAX( >>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + sizeof(ENDORSED_DIR) >>>>>> ) >>>>>> >>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>> >>>>>> But I'm fine with two different allocations. >>>>>> >>>>>> Thank you for addressing other concerns. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> see my comments inline. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>> malloc() in init_system_properties_values() >>>>>>>> >>>>>>>> Goetz, >>>>>>>> >>>>>>>> os_aix.cpp: 565 >>>>>>>> >>>>>>>> It might be better to allocate one buffer that satisfy all three >>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>> I need at least two allocations. The first one has a statically >>>>>>> known size. At >>>>>>> least more or less, as I know there will be only one path of >>>>>>> unknown size in the buffer. >>>>>>> The allocation in 556 must know about the length of the >>>>>>> getenv("LIBPATH") result, >>>>>>> which may contain several paths. >>>>>>> Also, in the other files, paths are concatenated, so at least two >>>>>>> buffers are needed. >>>>>>> >>>>>>>> os_bsd.cpp: 350 >>>>>>>> >>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, it makes >>>>>>>> code much more readable. >>>>>>> I'll fix this. >>>>>>> >>>>>>>> os_bsd.cpp: 485 >>>>>>>> >>>>>>>> you replace malloc to on-stack allocation of more than 4096 bytes. I >>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>> > see also comments to os_aix above - you can allocate large enough >>>>>>>> buffer once and than reuse it. >>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in the >>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>> The space required by the existing buf can be reused by the C >>>>>>> compiler. >>>>>>> >>>>>>> But I'll fix that and only use allocated memory. >>>>>>> I'll remove the buf that was already there and replace all spaces >>>>>>> I can estimate by MAXPATHLEN + some offset by a single, allocated >>>>>>> buffer. >>>>>>> I'll do this the same on all four platforms. >>>>>>> >>>>>>>> os_linux.cpp: 434 >>>>>>>> the same comments as above. >>>>>>>> >>>>>>>> os_solaris.cpp: 728 >>>>>>>> >>>>>>>> As soon as you doing cleanup, I would love to have this code >>>>>>>> changed >>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>> respect >>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>> variables. >>>>>>>> >>>>>>>> Could you change it to something like: >>>>>>>> Dl_serinfo info_sz, *info; >>>>>>> Yes, I'll fix that. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == -1) { >>>>>> ... >>>>>> >>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>> mtInternal); >>>>>> ... >>>>>> >>>>>> os_solaris.cpp: 829 >>>>>> The same comment about on-stack allocation as for os_bsd.cpp >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review and test this change. I please need a sponsor. >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>> >>>>>>> This change addresses the implementation of >>>>>>> init_system_properties_values >>>>>>> on aix, linux, solaris and bsd. >>>>>>> In init_system_properties_values a macro was defined mapping malloc to >>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful allocation >>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>> pointers as >>>>>>> allocated with real malloc, i.e., there were checks for NULL and >>>>>>> calls to free(). >>>>>>> >>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>> removes >>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>> local array where >>>>>>> possible. >>>>>>> >>>>>>> The allocated memory is passed to calls that end up at >>>>>>> SystemProperty::set_value(). >>>>>>> set_value copies the strings passed. Thus the memory allocated in >>>>>>> init_system_properties_values must be freed after these calls. >>>>>>> Most of these >>>>>>> frees were missing. >>>>>>> >>>>>>> This change adds the missing frees. >>>>>>> >>>>>>> Testing this change I ran into a warning in ppc code which I fixed, >>>>>>> too. >>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From luchsh at linux.vnet.ibm.com Tue Apr 1 14:52:27 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Tue, 1 Apr 2014 22:52:27 +0800 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Volker, Masayoshi, Thanks a lot for your review, here's the updated patch, could you pls take a look? http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis wrote: > Hi Jonathan, > > thanks for doing this change. Please find some comments below: > > 1. please update the copyright year to 2014 in every file you touch > Updated in new patch. > 2. in CopyFiles.gmk you can simplify the change by joining the windows > and aix cases because on Windows OPENJDK_TARGET_OS is the same like > OPENJDK_TARGET_OS_API_DIR. So you can write: > > ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) > > TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib > > $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings > $(call install-file) > > COPY_FILES += $(LIBDIR)/tzmappings > > endif > I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris' as I observed on my AIX box, solaris/lib is not the directory where tzmappings was stored for AIX. So I'm keeping this change, please fix me if I was wrong about the config. > > 3. regarding the changes proposed by Masayoshi: I agree that we should > put the AIX timezone mapping code in its own function, but I don't > think that getPlatformTimeZoneID() would be the right place. As far as > I understand, getPlatformTimeZoneID() is used to get a platform time > zone id if the environment variable "TZ" is not set. I don't know a > way how this could be done on AIX (@Jonathan: maybe you know?). If > there would be a way to get the time zone from some system files or > so, then we should put this code into the AIX version of > getPlatformTimeZoneID(). > I guess we may try to use /etc/envrionment file, which is basic setting for all processes, see http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm The implementation of getPlatformTimeZoneID() has been updated. > > But the current AIX code contributed by Jonathan, actually uses the > time zone id from the "TZ" environment variable and just maps it to a > Java compatible time zone id. So I'd suggest to refactor this code > into a function like for example "static const char* > mapPlatformToJavaTimzone(const char* tz)" and call that from > findJavaTZ_md(). I think that would make the code easier to > understand. > Agree, and have split the code into a separate static method to do the mapping work. > > @Masayoshi: what do you think, would you agree with such a solution. > > 4. I agree with Masayoshi that you should use the existing getGMTOffsetID() > Updated in new patch to eliminate duplication. > > 5. Please notice that your change breaks all Unix builds except AIX > because of: > > 759 } > 760 tzerr: > 761 if (javatz == NULL) { > 762 time_t offset; > ... > 782 } > 783 #endif > > I think that should read: > > 759 > 760 tzerr: > 761 if (javatz == NULL) { > 762 time_t offset; > ... > 782 } > 783 #endif > 784 } > > Refactoring the code in an extra function will make that error more > evident anyway. > > But please always build at least on one different platform (i.e. > Linux) to prevent such errors in the future. > My fault, sorry for the failure, should take no chance after any manual alteration. > > Regards, > Volker > > > On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu > wrote: > > Hi Jonathan, > > > > The AIX specific code looks OK to me. But I'd suggest the code be moved > to > > getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also > > there's a function for producing a fallback ID in "GMT?hh:mm", > > getGMTOffsetID() which can be called in tzerr. > > > > Thanks, > > Masayoshi > > > > > > On 3/26/2014 3:47 PM, Jonathan Lu wrote: > >> > >> Hi ppc-aix-port-dev, core-libs-dev, > >> > >> Here's a patch for JDK-8034220, > >> > >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ > >> > >> It is trying to add the a more complete timezone mapping mechanism for > AIX > >> platform. > >> the changes are primarily based on IBM's commercial JDK code, which > >> includes: > >> > >> - A new timezone mapping file added under directory jdk/src/aix/lib/ > >> - Code to parse above config file, changed file is > >> src/solaris/native/java/util/TimeZone_md.c > >> - And also makefile change in make/CopyFiles.gmk to copy the config file > >> > >> Could you pls help to review and give comments ? > >> > >> Cheers > >> - Jonathan > > > > > Many thanks Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Tue Apr 1 15:00:01 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 1 Apr 2014 17:00:01 +0200 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> Message-ID: I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within the stack bounds). I noticed this code in the windows signal handler: #ifdef _WIN64 // // If it's a legal stack address map the entire region in // PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; address addr = (address) exceptionRecord->ExceptionInformation[1]; if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { addr = (address)((uintptr_t)addr & (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); os::commit_memory((char *)addr, thread->stack_base() - addr, !ExecMem); return EXCEPTION_CONTINUE_EXECUTION; } else #endif If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? Roland. From vladimir.kozlov at oracle.com Tue Apr 1 20:54:10 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Apr 2014 13:54:10 -0700 Subject: hi (PPC64 build) In-Reply-To: <533B22A0.6060604@servergy.com> References: <533B22A0.6060604@servergy.com> Message-ID: <533B2772.9090200@oracle.com> It is question for ppc-aix-port-dev at openjdk.java.net Oracle does not support ppc-aix in 7u. Regards, Vladimir On 4/1/14 1:33 PM, Ruchika Kharwar wrote: > Hi, > I am new to hotspot and want to compile the hotspot code base on my ppc > platform. > > I cloned the hotspot code base > hg clone http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot > > Are there any pointers to the build instructions for this on a 64b ppc > platform ? > > Thank you > Regards > Ruchika > From vladimir.kozlov at oracle.com Tue Apr 1 21:36:52 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Apr 2014 14:36:52 -0700 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> Message-ID: <533B3174.5060301@oracle.com> The question is why you got EXCEPTION_ACCESS_VIOLATION for normal stack bang? May be it is 8026775 again when one page is skipped during banging. Windows requires sequential pages touche. Thanks, Vladimir On 4/1/14 8:00 AM, Roland Westrelin wrote: > I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within the stack bounds). I noticed this code in the windows signal handler: > > #ifdef _WIN64 > // > // If it's a legal stack address map the entire region in > // > PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; > address addr = (address) exceptionRecord->ExceptionInformation[1]; > if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { > addr = (address)((uintptr_t)addr & > (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); > os::commit_memory((char *)addr, thread->stack_base() - addr, > !ExecMem); > return EXCEPTION_CONTINUE_EXECUTION; > } > else > #endif > > If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? > > Roland. > From roland.westrelin at oracle.com Wed Apr 2 08:46:29 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 2 Apr 2014 10:46:29 +0200 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: <533B3174.5060301@oracle.com> References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> <533B3174.5060301@oracle.com> Message-ID: <25AA6D2D-A229-4FF1-9CB6-C0C502D108D2@oracle.com> > The question is why you got EXCEPTION_ACCESS_VIOLATION for normal stack bang? May be it is 8026775 again when one page is skipped during banging. Windows requires sequential pages touche. I wasn?t aware of this requirement on windows. Thanks, Vladimir. The interpreter bangs up to and including sp + StackShadowPages while the compiled code, with this change, bangs at sp + StackShadowPages + 1. So a page can be skipped and the requirement that all pages be touched sequentially cannot be guaranteed. So we either have to go back to banging at sp + StackShadowPages for the compiled code or enable the code that I pointed to in the signal on 32 bit. What do you think? Roland. > > Thanks, > Vladimir > > On 4/1/14 8:00 AM, Roland Westrelin wrote: >> I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within the stack bounds). I noticed this code in the windows signal handler: >> >> #ifdef _WIN64 >> // >> // If it's a legal stack address map the entire region in >> // >> PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; >> address addr = (address) exceptionRecord->ExceptionInformation[1]; >> if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { >> addr = (address)((uintptr_t)addr & >> (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); >> os::commit_memory((char *)addr, thread->stack_base() - addr, >> !ExecMem); >> return EXCEPTION_CONTINUE_EXECUTION; >> } >> else >> #endif >> >> If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? >> >> Roland. >> From volker.simonis at gmail.com Wed Apr 2 15:07:14 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 2 Apr 2014 17:07:14 +0200 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Jonathan, thanks for updating the change. Please find my comments inline: On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu wrote: > Hi Volker, Masayoshi, > > Thanks a lot for your review, here's the updated patch, could you pls take a > look? > > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ > > > On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis > wrote: >> >> Hi Jonathan, >> >> thanks for doing this change. Please find some comments below: >> >> 1. please update the copyright year to 2014 in every file you touch > > > Updated in new patch. > >> >> 2. in CopyFiles.gmk you can simplify the change by joining the windows >> and aix cases because on Windows OPENJDK_TARGET_OS is the same like >> OPENJDK_TARGET_OS_API_DIR. So you can write: >> >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) >> >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib >> >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings >> $(call install-file) >> >> COPY_FILES += $(LIBDIR)/tzmappings >> >> endif > > > I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris' > as I observed on my AIX box, > solaris/lib is not the directory where tzmappings was stored for AIX. > So I'm keeping this change, please fix me if I was wrong about the config. > Yes, but my point was to actually use OPENJDK_TARGET_OS for the construction of TZMAPPINGS_SRC as shown in the code snippet above. OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX and that should be just enough here. >> >> >> 3. regarding the changes proposed by Masayoshi: I agree that we should >> put the AIX timezone mapping code in its own function, but I don't >> think that getPlatformTimeZoneID() would be the right place. As far as >> I understand, getPlatformTimeZoneID() is used to get a platform time >> zone id if the environment variable "TZ" is not set. I don't know a >> way how this could be done on AIX (@Jonathan: maybe you know?). If >> there would be a way to get the time zone from some system files or >> so, then we should put this code into the AIX version of >> getPlatformTimeZoneID(). > > > I guess we may try to use /etc/envrionment file, which is basic setting for > all processes, > see > http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm > The implementation of getPlatformTimeZoneID() has been updated. > That's good! >> >> >> But the current AIX code contributed by Jonathan, actually uses the >> time zone id from the "TZ" environment variable and just maps it to a >> Java compatible time zone id. So I'd suggest to refactor this code >> into a function like for example "static const char* >> mapPlatformToJavaTimzone(const char* tz)" and call that from >> findJavaTZ_md(). I think that would make the code easier to >> understand. > > > Agree, and have split the code into a separate static method to do the > mapping work. > Good. But there's still one error in findJavaTZ_md(): 706 #ifdef _AIX 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); 708 #endif This should read: 706 #ifdef _AIX 707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz); 708 #endif because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came from getPlatformTimeZoneID(). With the above fixed I'll push this one we get one more review from a reviewer (I'm currently not an official reviewer). Regards, Volker >> >> >> @Masayoshi: what do you think, would you agree with such a solution. >> >> 4. I agree with Masayoshi that you should use the existing >> getGMTOffsetID() > > > Updated in new patch to eliminate duplication. > >> >> >> 5. Please notice that your change breaks all Unix builds except AIX >> because of: >> >> 759 } >> 760 tzerr: >> 761 if (javatz == NULL) { >> 762 time_t offset; >> ... >> 782 } >> 783 #endif >> >> I think that should read: >> >> 759 >> 760 tzerr: >> 761 if (javatz == NULL) { >> 762 time_t offset; >> ... >> 782 } >> 783 #endif >> 784 } >> >> Refactoring the code in an extra function will make that error more >> evident anyway. >> >> But please always build at least on one different platform (i.e. >> Linux) to prevent such errors in the future. > > > My fault, sorry for the failure, should take no chance after any manual > alteration. > >> >> >> Regards, >> Volker >> >> >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu >> wrote: >> > Hi Jonathan, >> > >> > The AIX specific code looks OK to me. But I'd suggest the code be moved >> > to >> > getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also >> > there's a function for producing a fallback ID in "GMT?hh:mm", >> > getGMTOffsetID() which can be called in tzerr. >> > >> > Thanks, >> > Masayoshi >> > >> > >> > On 3/26/2014 3:47 PM, Jonathan Lu wrote: >> >> >> >> Hi ppc-aix-port-dev, core-libs-dev, >> >> >> >> Here's a patch for JDK-8034220, >> >> >> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ >> >> >> >> It is trying to add the a more complete timezone mapping mechanism for >> >> AIX >> >> platform. >> >> the changes are primarily based on IBM's commercial JDK code, which >> >> includes: >> >> >> >> - A new timezone mapping file added under directory jdk/src/aix/lib/ >> >> - Code to parse above config file, changed file is >> >> src/solaris/native/java/util/TimeZone_md.c >> >> - And also makefile change in make/CopyFiles.gmk to copy the config >> >> file >> >> >> >> Could you pls help to review and give comments ? >> >> >> >> Cheers >> >> - Jonathan >> > >> > > > > Many thanks > Jonathan From vladimir.kozlov at oracle.com Wed Apr 2 16:03:45 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Apr 2014 09:03:45 -0700 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: <25AA6D2D-A229-4FF1-9CB6-C0C502D108D2@oracle.com> References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> <533B3174.5060301@oracle.com> <25AA6D2D-A229-4FF1-9CB6-C0C502D108D2@oracle.com> Message-ID: <533C34E1.7090801@oracle.com> I tried to tell about this during review ;) I thought using (<=StackShadowPages) from 8026775 changes should touch it. Can you spend sometime and write down in bug report about all places where we do stack bang and how much pages we bang so we can see whole picture? I think we should bang all sequential pages and do the same in all places. Banging StackShadowPages or StackShadowPages+1 is secondary if we do the same in all places. Thanks, Vladimir On 4/2/14 1:46 AM, Roland Westrelin wrote: >> The question is why you got EXCEPTION_ACCESS_VIOLATION for normal stack bang? May be it is 8026775 again when one page is skipped during banging. Windows requires sequential pages touche. > > I wasn?t aware of this requirement on windows. Thanks, Vladimir. > The interpreter bangs up to and including sp + StackShadowPages while the compiled code, with this change, bangs at sp + StackShadowPages + 1. So a page can be skipped and the requirement that all pages be touched sequentially cannot be guaranteed. So we either have to go back to banging at sp + StackShadowPages for the compiled code or enable the code that I pointed to in the signal on 32 bit. What do you think? > > Roland. > >> >> Thanks, >> Vladimir >> >> On 4/1/14 8:00 AM, Roland Westrelin wrote: >>> I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within the stack bounds). I noticed this code in the windows signal handler: >>> >>> #ifdef _WIN64 >>> // >>> // If it's a legal stack address map the entire region in >>> // >>> PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; >>> address addr = (address) exceptionRecord->ExceptionInformation[1]; >>> if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { >>> addr = (address)((uintptr_t)addr & >>> (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); >>> os::commit_memory((char *)addr, thread->stack_base() - addr, >>> !ExecMem); >>> return EXCEPTION_CONTINUE_EXECUTION; >>> } >>> else >>> #endif >>> >>> If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? >>> >>> Roland. >>> > From luchsh at linux.vnet.ibm.com Wed Apr 2 16:34:02 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Thu, 3 Apr 2014 00:34:02 +0800 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Volker, On 2014?04?02? 23:07, Volker Simonis wrote: Hi Jonathan, thanks for updating the change. Please find my comments inline: On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu wrote: Hi Volker, Masayoshi, Thanks a lot for your review, here's the updated patch, could you pls take a look? http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis wrote: Hi Jonathan, thanks for doing this change. Please find some comments below: 1. please update the copyright year to 2014 in every file you touch Updated in new patch. 2. in CopyFiles.gmk you can simplify the change by joining the windows and aix cases because on Windows OPENJDK_TARGET_OS is the same like OPENJDK_TARGET_OS_API_DIR. So you can write: ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings $(call install-file) COPY_FILES += $(LIBDIR)/tzmappings endif I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris' as I observed on my AIX box, solaris/lib is not the directory where tzmappings was stored for AIX. So I'm keeping this change, please fix me if I was wrong about the config. Yes, but my point was to actually use OPENJDK_TARGET_OS for the construction of TZMAPPINGS_SRC as shown in the code snippet above. OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX and that should be just enough here. That's right, let me try that and also build/test on Windows platform. 3. regarding the changes proposed by Masayoshi: I agree that we should put the AIX timezone mapping code in its own function, but I don't think that getPlatformTimeZoneID() would be the right place. As far as I understand, getPlatformTimeZoneID() is used to get a platform time zone id if the environment variable "TZ" is not set. I don't know a way how this could be done on AIX (@Jonathan: maybe you know?). If there would be a way to get the time zone from some system files or so, then we should put this code into the AIX version of getPlatformTimeZoneID(). I guess we may try to use /etc/envrionment file, which is basic setting for all processes, seehttp://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm The implementation of getPlatformTimeZoneID() has been updated. That's good! But the current AIX code contributed by Jonathan, actually uses the time zone id from the "TZ" environment variable and just maps it to a Java compatible time zone id. So I'd suggest to refactor this code into a function like for example "static const char* mapPlatformToJavaTimzone(const char* tz)" and call that from findJavaTZ_md(). I think that would make the code easier to understand. Agree, and have split the code into a separate static method to do the mapping work. Good. But there's still one error in findJavaTZ_md(): 706 #ifdef _AIX 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); 708 #endif This should read: 706 #ifdef _AIX 707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz); 708 #endif because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came from getPlatformTimeZoneID(). Right, but with the second approach, there may be a minor memory leak here, as javatz was not freed before being overwritten on AIX. will post another patch on this soon. With the above fixed I'll push this one we get one more review from a reviewer (I'm currently not an official reviewer). Regards, Volker @Masayoshi: what do you think, would you agree with such a solution. 4. I agree with Masayoshi that you should use the existing getGMTOffsetID() Updated in new patch to eliminate duplication. 5. Please notice that your change breaks all Unix builds except AIX because of: 759 } 760 tzerr: 761 if (javatz == NULL) { 762 time_t offset; ... 782 } 783 #endif I think that should read: 759 760 tzerr: 761 if (javatz == NULL) { 762 time_t offset; ... 782 } 783 #endif 784 } Refactoring the code in an extra function will make that error more evident anyway. But please always build at least on one different platform (i.e. Linux) to prevent such errors in the future. My fault, sorry for the failure, should take no chance after any manual alteration. Regards, Volker On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu wrote: Hi Jonathan, The AIX specific code looks OK to me. But I'd suggest the code be moved to getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also there's a function for producing a fallback ID in "GMT?hh:mm", getGMTOffsetID() which can be called in tzerr. Thanks, Masayoshi On 3/26/2014 3:47 PM, Jonathan Lu wrote: Hi ppc-aix-port-dev, core-libs-dev, Here's a patch for JDK-8034220, http://cr.openjdk.java.net/~luchsh/JDK-8034220/ It is trying to add the a more complete timezone mapping mechanism for AIX platform. the changes are primarily based on IBM's commercial JDK code, which includes: - A new timezone mapping file added under directory jdk/src/aix/lib/ - Code to parse above config file, changed file is src/solaris/native/java/util/TimeZone_md.c - And also makefile change in make/CopyFiles.gmk to copy the config file Could you pls help to review and give comments ? Cheers - Jonathan Many thanks Jonathan Regards Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Apr 2 23:30:15 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Apr 2014 16:30:15 -0700 Subject: [8u20] Request for approval: 8036767: PPC64: Support for little endian execution model Message-ID: <533C9D87.9030301@oracle.com> Please approve backport of ppc64 changes to support little endian. Changes will be pushed through Hotspot repository jdk8u/hs-dev because they have Hotspot changes. Changes applied cleanly (hotspot and top) but I have to regenerate generated-configure.sh (open and closed parts). Bug: https://bugs.openjdk.java.net/browse/JDK-8036767 JDK 9 Changesets: http://hg.openjdk.java.net/jdk9/hs-comp/rev/28e272c4b976 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/09edc8e9fa4d Reviews: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013193.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013206.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013287.html Thanks, Vladimir From igor.veresov at oracle.com Wed Apr 2 23:56:51 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 2 Apr 2014 16:56:51 -0700 Subject: [8u20] Request for approval: 8036767: PPC64: Support for little endian execution model In-Reply-To: <533C9D87.9030301@oracle.com> References: <533C9D87.9030301@oracle.com> Message-ID: <64227108-ED03-43B3-9440-FD12FB74E757@oracle.com> Looks fine to me. igor On Apr 2, 2014, at 4:30 PM, Vladimir Kozlov wrote: > Please approve backport of ppc64 changes to support little endian. > Changes will be pushed through Hotspot repository jdk8u/hs-dev because they have Hotspot changes. > > Changes applied cleanly (hotspot and top) but I have to regenerate generated-configure.sh (open and closed parts). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8036767 > > JDK 9 Changesets: > http://hg.openjdk.java.net/jdk9/hs-comp/rev/28e272c4b976 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/09edc8e9fa4d > > Reviews: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013193.html > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013206.html > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013287.html > > Thanks, > Vladimir From sean.coffey at oracle.com Thu Apr 3 09:15:04 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 03 Apr 2014 10:15:04 +0100 Subject: [8u20] Request for approval: 8036767: PPC64: Support for little endian execution model In-Reply-To: <64227108-ED03-43B3-9440-FD12FB74E757@oracle.com> References: <533C9D87.9030301@oracle.com> <64227108-ED03-43B3-9440-FD12FB74E757@oracle.com> Message-ID: <533D2698.2020908@oracle.com> Vladimir, no jdk8u-dev approval is necessary for pushing hotspot changes to the hotspot team forest. Alejandro will look after the approval request when he does the bulk push into jdk8u master. regards, Sean. On 03/04/2014 00:56, Igor Veresov wrote: > Looks fine to me. > > igor > > On Apr 2, 2014, at 4:30 PM, Vladimir Kozlov wrote: > >> Please approve backport of ppc64 changes to support little endian. >> Changes will be pushed through Hotspot repository jdk8u/hs-dev because they have Hotspot changes. >> >> Changes applied cleanly (hotspot and top) but I have to regenerate generated-configure.sh (open and closed parts). >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8036767 >> >> JDK 9 Changesets: >> http://hg.openjdk.java.net/jdk9/hs-comp/rev/28e272c4b976 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/09edc8e9fa4d >> >> Reviews: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013193.html >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013206.html >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013287.html >> >> Thanks, >> Vladimir From vladimir.kozlov at oracle.com Thu Apr 3 14:45:19 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Apr 2014 07:45:19 -0700 Subject: [8u20] Request for approval: 8036767: PPC64: Support for little endian execution model In-Reply-To: <533D2698.2020908@oracle.com> References: <533C9D87.9030301@oracle.com> <64227108-ED03-43B3-9440-FD12FB74E757@oracle.com> <533D2698.2020908@oracle.com> Message-ID: <533D73FF.8000502@oracle.com> Thank you, Sean On 4/3/14 2:15 AM, Se?n Coffey wrote: > Vladimir, > > no jdk8u-dev approval is necessary for pushing hotspot changes to the hotspot team forest. Alejandro will look after the > approval request when he does the bulk push into jdk8u master. It was not clear for me if this rule is applied only to hotspot changes or whole forest. Thanks, Vladimir > > regards, > Sean. > > On 03/04/2014 00:56, Igor Veresov wrote: >> Looks fine to me. >> >> igor >> >> On Apr 2, 2014, at 4:30 PM, Vladimir Kozlov wrote: >> >>> Please approve backport of ppc64 changes to support little endian. >>> Changes will be pushed through Hotspot repository jdk8u/hs-dev because they have Hotspot changes. >>> >>> Changes applied cleanly (hotspot and top) but I have to regenerate generated-configure.sh (open and closed parts). >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8036767 >>> >>> JDK 9 Changesets: >>> http://hg.openjdk.java.net/jdk9/hs-comp/rev/28e272c4b976 >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/09edc8e9fa4d >>> >>> Reviews: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013193.html >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013206.html >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-March/013287.html >>> >>> Thanks, >>> Vladimir > From luchsh at linux.vnet.ibm.com Fri Apr 4 08:18:32 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Fri, 4 Apr 2014 16:18:32 +0800 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Volker, Masayoshi, I made another patch which fixed the problems mentioned in last mail, http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ Could you pls help to take a look? Many thanks Jonathan On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu wrote: > Hi Volker, > > > On 2014?04?02? 23:07, Volker Simonis wrote: > > Hi Jonathan, > > thanks for updating the change. Please find my comments inline: > > On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu wrote: > > Hi Volker, Masayoshi, > > Thanks a lot for your review, here's the updated patch, could you pls take a > look? > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ > > > On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis > wrote: > > Hi Jonathan, > > thanks for doing this change. Please find some comments below: > > 1. please update the copyright year to 2014 in every file you touch > > Updated in new patch. > > > 2. in CopyFiles.gmk you can simplify the change by joining the windows > and aix cases because on Windows OPENJDK_TARGET_OS is the same like > OPENJDK_TARGET_OS_API_DIR. So you can write: > > ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) > > TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib > > $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings > $(call install-file) > > COPY_FILES += $(LIBDIR)/tzmappings > > endif > > I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is 'solaris' > as I observed on my AIX box, > solaris/lib is not the directory where tzmappings was stored for AIX. > So I'm keeping this change, please fix me if I was wrong about the config. > > > Yes, but my point was to actually use OPENJDK_TARGET_OS for the > construction of TZMAPPINGS_SRC as shown in the code snippet above. > OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX > and that should be just enough here. > > > That's right, let me try that and also build/test on Windows platform. > > > 3. regarding the changes proposed by Masayoshi: I agree that we should > put the AIX timezone mapping code in its own function, but I don't > think that getPlatformTimeZoneID() would be the right place. As far as > I understand, getPlatformTimeZoneID() is used to get a platform time > zone id if the environment variable "TZ" is not set. I don't know a > way how this could be done on AIX (@Jonathan: maybe you know?). If > there would be a way to get the time zone from some system files or > so, then we should put this code into the AIX version of > getPlatformTimeZoneID(). > > I guess we may try to use /etc/envrionment file, which is basic setting for > all processes, > seehttp://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm > The implementation of getPlatformTimeZoneID() has been updated. > > > That's good! > > > But the current AIX code contributed by Jonathan, actually uses the > time zone id from the "TZ" environment variable and just maps it to a > Java compatible time zone id. So I'd suggest to refactor this code > into a function like for example "static const char* > mapPlatformToJavaTimzone(const char* tz)" and call that from > findJavaTZ_md(). I think that would make the code easier to > understand. > > Agree, and have split the code into a separate static method to do the > mapping work. > > > Good. But there's still one error in findJavaTZ_md(): > > 706 #ifdef _AIX > 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); > 708 #endif > > This should read: > > 706 #ifdef _AIX > 707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz); > 708 #endif > > because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came > from getPlatformTimeZoneID(). > > > Right, but with the second approach, there may be a minor memory leak here, > as javatz was not freed before being overwritten on AIX. will post another > patch on this soon. > > > With the above fixed I'll push this one we get one more review from a > reviewer (I'm currently not an official reviewer). > > Regards, > Volker > > > > @Masayoshi: what do you think, would you agree with such a solution. > > 4. I agree with Masayoshi that you should use the existing > getGMTOffsetID() > > Updated in new patch to eliminate duplication. > > > 5. Please notice that your change breaks all Unix builds except AIX > because of: > > 759 } > 760 tzerr: > 761 if (javatz == NULL) { > 762 time_t offset; > ... > 782 } > 783 #endif > > I think that should read: > > 759 > 760 tzerr: > 761 if (javatz == NULL) { > 762 time_t offset; > ... > 782 } > 783 #endif > 784 } > > Refactoring the code in an extra function will make that error more > evident anyway. > > But please always build at least on one different platform (i.e. > Linux) to prevent such errors in the future. > > My fault, sorry for the failure, should take no chance after any manual > alteration. > > > Regards, > Volker > > > On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu wrote: > > Hi Jonathan, > > The AIX specific code looks OK to me. But I'd suggest the code be moved > to > getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also > there's a function for producing a fallback ID in "GMT?hh:mm", > getGMTOffsetID() which can be called in tzerr. > > Thanks, > Masayoshi > > > On 3/26/2014 3:47 PM, Jonathan Lu wrote: > > Hi ppc-aix-port-dev, core-libs-dev, > > Here's a patch for JDK-8034220, > http://cr.openjdk.java.net/~luchsh/JDK-8034220/ > > It is trying to add the a more complete timezone mapping mechanism for > AIX > platform. > the changes are primarily based on IBM's commercial JDK code, which > includes: > > - A new timezone mapping file added under directory jdk/src/aix/lib/ > - Code to parse above config file, changed file is > src/solaris/native/java/util/TimeZone_md.c > - And also makefile change in make/CopyFiles.gmk to copy the config > file > > Could you pls help to review and give comments ? > > Cheers > - Jonathan > > Many thanks > Jonathan > > Regards > Jonathan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Apr 4 13:22:33 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 4 Apr 2014 15:22:33 +0200 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Jonathan, sorry, but I found a few more issues: - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise somebody could easily crash the VM by specifying a TZ with more than 100 characters. - you can delete the lines 871-872 because the variables are actually not used and you can also remove the handling for "timezone == 0" because that is actually done in getGMTOffsetID() anyway. - could you please avoid the usage of strtok. It is not intended for usage in a multithreaded environment (see for example "man strtok" on AIX). strtok_r is probably overkill, but you could use for example strchr. did you check the build on Windows? Thank you and best regards, Volker On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu wrote: > Hi Volker, Masayoshi, > > I made another patch which fixed the problems mentioned in last mail, > > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ > > Could you pls help to take a look? > > Many thanks > Jonathan > > > > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu > wrote: >> >> Hi Volker, >> >> >> On 2014?04?02? 23:07, Volker Simonis wrote: >> >> Hi Jonathan, >> >> thanks for updating the change. Please find my comments inline: >> >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu >> wrote: >> >> Hi Volker, Masayoshi, >> >> Thanks a lot for your review, here's the updated patch, could you pls take >> a >> look? >> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ >> >> >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis >> wrote: >> >> Hi Jonathan, >> >> thanks for doing this change. Please find some comments below: >> >> 1. please update the copyright year to 2014 in every file you touch >> >> Updated in new patch. >> >> 2. in CopyFiles.gmk you can simplify the change by joining the windows >> and aix cases because on Windows OPENJDK_TARGET_OS is the same like >> OPENJDK_TARGET_OS_API_DIR. So you can write: >> >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) >> >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib >> >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings >> $(call install-file) >> >> COPY_FILES += $(LIBDIR)/tzmappings >> >> endif >> >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is >> 'solaris' >> as I observed on my AIX box, >> solaris/lib is not the directory where tzmappings was stored for AIX. >> So I'm keeping this change, please fix me if I was wrong about the config. >> >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the >> construction of TZMAPPINGS_SRC as shown in the code snippet above. >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX >> and that should be just enough here. >> >> >> That's right, let me try that and also build/test on Windows platform. >> >> >> 3. regarding the changes proposed by Masayoshi: I agree that we should >> put the AIX timezone mapping code in its own function, but I don't >> think that getPlatformTimeZoneID() would be the right place. As far as >> I understand, getPlatformTimeZoneID() is used to get a platform time >> zone id if the environment variable "TZ" is not set. I don't know a >> way how this could be done on AIX (@Jonathan: maybe you know?). If >> there would be a way to get the time zone from some system files or >> so, then we should put this code into the AIX version of >> getPlatformTimeZoneID(). >> >> I guess we may try to use /etc/envrionment file, which is basic setting >> for >> all processes, >> see >> >> http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm >> The implementation of getPlatformTimeZoneID() has been updated. >> >> That's good! >> >> But the current AIX code contributed by Jonathan, actually uses the >> time zone id from the "TZ" environment variable and just maps it to a >> Java compatible time zone id. So I'd suggest to refactor this code >> into a function like for example "static const char* >> mapPlatformToJavaTimzone(const char* tz)" and call that from >> findJavaTZ_md(). I think that would make the code easier to >> understand. >> >> Agree, and have split the code into a separate static method to do the >> mapping work. >> >> Good. But there's still one error in findJavaTZ_md(): >> >> 706 #ifdef _AIX >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); >> 708 #endif >> >> This should read: >> >> 706 #ifdef _AIX >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz); >> 708 #endif >> >> because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came >> from getPlatformTimeZoneID(). >> >> >> Right, but with the second approach, there may be a minor memory leak >> here, >> as javatz was not freed before being overwritten on AIX. will post another >> patch on this soon. >> >> >> With the above fixed I'll push this one we get one more review from a >> reviewer (I'm currently not an official reviewer). >> >> Regards, >> Volker >> >> >> @Masayoshi: what do you think, would you agree with such a solution. >> >> 4. I agree with Masayoshi that you should use the existing >> getGMTOffsetID() >> >> Updated in new patch to eliminate duplication. >> >> 5. Please notice that your change breaks all Unix builds except AIX >> because of: >> >> 759 } >> 760 tzerr: >> 761 if (javatz == NULL) { >> 762 time_t offset; >> ... >> 782 } >> 783 #endif >> >> I think that should read: >> >> 759 >> 760 tzerr: >> 761 if (javatz == NULL) { >> 762 time_t offset; >> ... >> 782 } >> 783 #endif >> 784 } >> >> Refactoring the code in an extra function will make that error more >> evident anyway. >> >> But please always build at least on one different platform (i.e. >> Linux) to prevent such errors in the future. >> >> My fault, sorry for the failure, should take no chance after any manual >> alteration. >> >> Regards, >> Volker >> >> >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu >> wrote: >> >> Hi Jonathan, >> >> The AIX specific code looks OK to me. But I'd suggest the code be moved >> to >> getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also >> there's a function for producing a fallback ID in "GMT?hh:mm", >> getGMTOffsetID() which can be called in tzerr. >> >> Thanks, >> Masayoshi >> >> >> On 3/26/2014 3:47 PM, Jonathan Lu wrote: >> >> Hi ppc-aix-port-dev, core-libs-dev, >> >> Here's a patch for JDK-8034220, >> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ >> >> It is trying to add the a more complete timezone mapping mechanism for >> AIX >> platform. >> the changes are primarily based on IBM's commercial JDK code, which >> includes: >> >> - A new timezone mapping file added under directory jdk/src/aix/lib/ >> - Code to parse above config file, changed file is >> src/solaris/native/java/util/TimeZone_md.c >> - And also makefile change in make/CopyFiles.gmk to copy the config >> file >> >> Could you pls help to review and give comments ? >> >> Cheers >> - Jonathan >> >> Many thanks >> Jonathan >> >> Regards >> Jonathan > > From vladimir.kozlov at oracle.com Tue Apr 8 20:32:50 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Apr 2014 13:32:50 -0700 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <533AB62D.1010501@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> Message-ID: <53445CF2.50909@oracle.com> Hi Dmitry, Could you tell when you are planning to backport these changes into 8u20? Thanks, Vladimir On 4/1/14 5:50 AM, Dmitry Samersoff wrote: > Goetz, > > Push done. > > Let it bakes for some times in JDK9 (at least two nightlies) than I'll > push it to 8u20 > > -Dmitry > > On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >> Thanks Dmitry and Vladimir! >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Thursday, March 27, 2014 8:18 PM >> To: Dmitry Samersoff; Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() >> >> Thank you, Dmitry >> >> We need to backport it into 8u20 too. >> >> Regards, >> Vladimir >> >> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>> Vladimir, >>> >>> I can push it to RT next week. >>> >>> -Dmitry >>> >>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>> Goetz, >>>>> >>>>> Looks good for me! >>>> >>>> +1. >>>> >>>> Dmitry, >>>> >>>> Do you want me to push it into Comp repo or you will do it into RT repo? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>> I had a look at set_boot_path(). That will never return false, >>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>> In addition it would be wrong to return, there should be a >>>>>> call to vm_exit_... >>>>>> So I removed the test and return statement. >>>>>> I added the other missing FREEs. >>>>>> >>>>>> I also implemented your proposal with only one sprintf >>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>> to get it more similar. Solaris seems too different to >>>>>> adapt to that scheme. >>>>>> >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>> in init_system_properties_values() >>>>>> >>>>>> Goetz, >>>>>> >>>>>> Thank you for doing it - code is much cleaner now. >>>>>> >>>>>> os_aix.cpp: >>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>> >>>>>> os_bsd.cpp: >>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>> >>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>> >>>>>> >>>>>> ll.497 (and below) a trick like one below: >>>>>> >>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>> char *v_colon = ":"; >>>>>> >>>>>> if (l != NULL || v != NULL) { >>>>>> >>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>> >>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>> >>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, ld_library_path); >>>>>> if (ld_library_path != buf){ ... /* free ld_library_path */ } >>>>>> ld_library_path = t; >>>>>> } >>>>>> >>>>>> might be useful to assemble the path in one shot, >>>>>> without extra copying >>>>>> >>>>>> >>>>>> ll.520 As you appending constant value ":.", you can just >>>>>> take it into account at ll. 495 >>>>>> >>>>>> >>>>>> os_linux.cpp: >>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>> >>>>>> os_solaris.cpp: >>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>> >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please have a look at this new webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>> >>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>> the missing parts in here, below. >>>>>>> >>>>>>> Avoiding big stack allocations I wanted to remove the buf[MAXPATHLEN] >>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>> get along >>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>> >>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>> readability of the code. >>>>>>> >>>>>>> So now I compute the max size of all buffers I can estimate at the >>>>>>> beginning >>>>>>> and do a single allocation for them. >>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Goetz, >>>>>>> >>>>>>>> The allocation in 556 must know about the length of the >>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>> >>>>>>> You can use >>>>>>> >>>>>>> MAX( >>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + sizeof(ENDORSED_DIR) >>>>>>> ) >>>>>>> >>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>> >>>>>>> But I'm fine with two different allocations. >>>>>>> >>>>>>> Thank you for addressing other concerns. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> see my comments inline. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> os_aix.cpp: 565 >>>>>>>>> >>>>>>>>> It might be better to allocate one buffer that satisfy all three >>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>> known size. At >>>>>>>> least more or less, as I know there will be only one path of >>>>>>>> unknown size in the buffer. >>>>>>>> The allocation in 556 must know about the length of the >>>>>>>> getenv("LIBPATH") result, >>>>>>>> which may contain several paths. >>>>>>>> Also, in the other files, paths are concatenated, so at least two >>>>>>>> buffers are needed. >>>>>>>> >>>>>>>>> os_bsd.cpp: 350 >>>>>>>>> >>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, it makes >>>>>>>>> code much more readable. >>>>>>>> I'll fix this. >>>>>>>> >>>>>>>>> os_bsd.cpp: 485 >>>>>>>>> >>>>>>>>> you replace malloc to on-stack allocation of more than 4096 bytes. I >>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>> > see also comments to os_aix above - you can allocate large enough >>>>>>>>> buffer once and than reuse it. >>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in the >>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>> compiler. >>>>>>>> >>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>> I'll remove the buf that was already there and replace all spaces >>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, allocated >>>>>>>> buffer. >>>>>>>> I'll do this the same on all four platforms. >>>>>>>> >>>>>>>>> os_linux.cpp: 434 >>>>>>>>> the same comments as above. >>>>>>>>> >>>>>>>>> os_solaris.cpp: 728 >>>>>>>>> >>>>>>>>> As soon as you doing cleanup, I would love to have this code >>>>>>>>> changed >>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>> respect >>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>> variables. >>>>>>>>> >>>>>>>>> Could you change it to something like: >>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>> Yes, I'll fix that. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == -1) { >>>>>>> ... >>>>>>> >>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>> mtInternal); >>>>>>> ... >>>>>>> >>>>>>> os_solaris.cpp: 829 >>>>>>> The same comment about on-stack allocation as for os_bsd.cpp >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>> >>>>>>>> This change addresses the implementation of >>>>>>>> init_system_properties_values >>>>>>>> on aix, linux, solaris and bsd. >>>>>>>> In init_system_properties_values a macro was defined mapping malloc to >>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful allocation >>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>> pointers as >>>>>>>> allocated with real malloc, i.e., there were checks for NULL and >>>>>>>> calls to free(). >>>>>>>> >>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>> removes >>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>> local array where >>>>>>>> possible. >>>>>>>> >>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>> SystemProperty::set_value(). >>>>>>>> set_value copies the strings passed. Thus the memory allocated in >>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>> Most of these >>>>>>>> frees were missing. >>>>>>>> >>>>>>>> This change adds the missing frees. >>>>>>>> >>>>>>>> Testing this change I ran into a warning in ppc code which I fixed, >>>>>>>> too. >>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> >>> > > From dmitry.samersoff at oracle.com Tue Apr 8 21:19:07 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 09 Apr 2014 01:19:07 +0400 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53445CF2.50909@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> Message-ID: <534467CB.8010307@oracle.com> Vladimir, On 2014-04-09 00:32, Vladimir Kozlov wrote: > Could you tell when you are planning to backport these changes into 8u20? This week. Do I need any additional approvals? -Dmitry > > Thanks, > Vladimir > > On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >> Goetz, >> >> Push done. >> >> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >> push it to 8u20 >> >> -Dmitry >> >> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>> Thanks Dmitry and Vladimir! >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Thursday, March 27, 2014 8:18 PM >>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>> in init_system_properties_values() >>> >>> Thank you, Dmitry >>> >>> We need to backport it into 8u20 too. >>> >>> Regards, >>> Vladimir >>> >>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>> Vladimir, >>>> >>>> I can push it to RT next week. >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>> Goetz, >>>>>> >>>>>> Looks good for me! >>>>> >>>>> +1. >>>>> >>>>> Dmitry, >>>>> >>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>> repo? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>> In addition it would be wrong to return, there should be a >>>>>>> call to vm_exit_... >>>>>>> So I removed the test and return statement. >>>>>>> I added the other missing FREEs. >>>>>>> >>>>>>> I also implemented your proposal with only one sprintf >>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>> to get it more similar. Solaris seems too different to >>>>>>> adapt to that scheme. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>>> in init_system_properties_values() >>>>>>> >>>>>>> Goetz, >>>>>>> >>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>> >>>>>>> os_aix.cpp: >>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>> >>>>>>> os_bsd.cpp: >>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>> >>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>> >>>>>>> >>>>>>> ll.497 (and below) a trick like one below: >>>>>>> >>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>> char *v_colon = ":"; >>>>>>> >>>>>>> if (l != NULL || v != NULL) { >>>>>>> >>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>> >>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>> >>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, ld_library_path); >>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>> ld_library_path */ } >>>>>>> ld_library_path = t; >>>>>>> } >>>>>>> >>>>>>> might be useful to assemble the path in one shot, >>>>>>> without extra copying >>>>>>> >>>>>>> >>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>> take it into account at ll. 495 >>>>>>> >>>>>>> >>>>>>> os_linux.cpp: >>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>> >>>>>>> os_solaris.cpp: >>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>> >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please have a look at this new webrev: >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>> >>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>> the missing parts in here, below. >>>>>>>> >>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>> buf[MAXPATHLEN] >>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>> get along >>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>> >>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>> readability of the code. >>>>>>>> >>>>>>>> So now I compute the max size of all buffers I can estimate at the >>>>>>>> beginning >>>>>>>> and do a single allocation for them. >>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Goetz, >>>>>>>> >>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>> >>>>>>>> You can use >>>>>>>> >>>>>>>> MAX( >>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + sizeof(ENDORSED_DIR) >>>>>>>> ) >>>>>>>> >>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>> >>>>>>>> But I'm fine with two different allocations. >>>>>>>> >>>>>>>> Thank you for addressing other concerns. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> see my comments inline. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>> >>>>>>>>>> It might be better to allocate one buffer that satisfy all three >>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>> known size. At >>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>> unknown size in the buffer. >>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>> getenv("LIBPATH") result, >>>>>>>>> which may contain several paths. >>>>>>>>> Also, in the other files, paths are concatenated, so at least two >>>>>>>>> buffers are needed. >>>>>>>>> >>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>> >>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>> it makes >>>>>>>>>> code much more readable. >>>>>>>>> I'll fix this. >>>>>>>>> >>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>> >>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>> bytes. I >>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>> large enough >>>>>>>>>> buffer once and than reuse it. >>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>> the >>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>> compiler. >>>>>>>>> >>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>> I'll remove the buf that was already there and replace all spaces >>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, allocated >>>>>>>>> buffer. >>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>> >>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>> the same comments as above. >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>> >>>>>>>>>> As soon as you doing cleanup, I would love to have this code >>>>>>>>>> changed >>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>> respect >>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>> variables. >>>>>>>>>> >>>>>>>>>> Could you change it to something like: >>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>> Yes, I'll fix that. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>> -1) { >>>>>>>> ... >>>>>>>> >>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>> mtInternal); >>>>>>>> ... >>>>>>>> >>>>>>>> os_solaris.cpp: 829 >>>>>>>> The same comment about on-stack allocation as for os_bsd.cpp >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>> >>>>>>>>> This change addresses the implementation of >>>>>>>>> init_system_properties_values >>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>> malloc to >>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>> allocation >>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>> pointers as >>>>>>>>> allocated with real malloc, i.e., there were checks for NULL and >>>>>>>>> calls to free(). >>>>>>>>> >>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>> removes >>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>> local array where >>>>>>>>> possible. >>>>>>>>> >>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>> SystemProperty::set_value(). >>>>>>>>> set_value copies the strings passed. Thus the memory allocated in >>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>> Most of these >>>>>>>>> frees were missing. >>>>>>>>> >>>>>>>>> This change adds the missing frees. >>>>>>>>> >>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>> fixed, >>>>>>>>> too. >>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From vladimir.kozlov at oracle.com Tue Apr 8 21:43:38 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Apr 2014 14:43:38 -0700 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <534467CB.8010307@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> Message-ID: <53446D8A.5020207@oracle.com> On 4/8/14 2:19 PM, Dmitry Samersoff wrote: > Vladimir, > > On 2014-04-09 00:32, Vladimir Kozlov wrote: > >> Could you tell when you are planning to backport these changes into 8u20? > > This week. Do I need any additional approvals? No need for approval but, please, send new [8u20] RFR to hotspot-dev with links to jbs and jdk9 changeset and say that it applies cleanly (if it is). I will review it and you can push. It is to let people know that you backport it. Thanks, Vladimir > > -Dmitry > >> >> Thanks, >> Vladimir >> >> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>> Goetz, >>> >>> Push done. >>> >>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>> push it to 8u20 >>> >>> -Dmitry >>> >>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>> Thanks Dmitry and Vladimir! >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Thursday, March 27, 2014 8:18 PM >>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>> in init_system_properties_values() >>>> >>>> Thank you, Dmitry >>>> >>>> We need to backport it into 8u20 too. >>>> >>>> Regards, >>>> Vladimir >>>> >>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>> Vladimir, >>>>> >>>>> I can push it to RT next week. >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>> Goetz, >>>>>>> >>>>>>> Looks good for me! >>>>>> >>>>>> +1. >>>>>> >>>>>> Dmitry, >>>>>> >>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>> repo? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>> call to vm_exit_... >>>>>>>> So I removed the test and return statement. >>>>>>>> I added the other missing FREEs. >>>>>>>> >>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>> adapt to that scheme. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>>>> in init_system_properties_values() >>>>>>>> >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>> >>>>>>>> os_aix.cpp: >>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>> >>>>>>>> os_bsd.cpp: >>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>> >>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>> >>>>>>>> >>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>> >>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>> char *v_colon = ":"; >>>>>>>> >>>>>>>> if (l != NULL || v != NULL) { >>>>>>>> >>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>> >>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>> >>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, ld_library_path); >>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>> ld_library_path */ } >>>>>>>> ld_library_path = t; >>>>>>>> } >>>>>>>> >>>>>>>> might be useful to assemble the path in one shot, >>>>>>>> without extra copying >>>>>>>> >>>>>>>> >>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>> take it into account at ll. 495 >>>>>>>> >>>>>>>> >>>>>>>> os_linux.cpp: >>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>> >>>>>>>> os_solaris.cpp: >>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> please have a look at this new webrev: >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>> >>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>> the missing parts in here, below. >>>>>>>>> >>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>> buf[MAXPATHLEN] >>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>> get along >>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>> >>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>> readability of the code. >>>>>>>>> >>>>>>>>> So now I compute the max size of all buffers I can estimate at the >>>>>>>>> beginning >>>>>>>>> and do a single allocation for them. >>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>> >>>>>>>>> You can use >>>>>>>>> >>>>>>>>> MAX( >>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + sizeof(ENDORSED_DIR) >>>>>>>>> ) >>>>>>>>> >>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>> >>>>>>>>> But I'm fine with two different allocations. >>>>>>>>> >>>>>>>>> Thank you for addressing other concerns. >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> see my comments inline. >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>> >>>>>>>>>>> Goetz, >>>>>>>>>>> >>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>> >>>>>>>>>>> It might be better to allocate one buffer that satisfy all three >>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>> known size. At >>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>> unknown size in the buffer. >>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>> which may contain several paths. >>>>>>>>>> Also, in the other files, paths are concatenated, so at least two >>>>>>>>>> buffers are needed. >>>>>>>>>> >>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>> >>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>> it makes >>>>>>>>>>> code much more readable. >>>>>>>>>> I'll fix this. >>>>>>>>>> >>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>> >>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>> bytes. I >>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>> large enough >>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>> the >>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>> compiler. >>>>>>>>>> >>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>> I'll remove the buf that was already there and replace all spaces >>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, allocated >>>>>>>>>> buffer. >>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>> >>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>> the same comments as above. >>>>>>>>>>> >>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>> >>>>>>>>>>> As soon as you doing cleanup, I would love to have this code >>>>>>>>>>> changed >>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>> respect >>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>> variables. >>>>>>>>>>> >>>>>>>>>>> Could you change it to something like: >>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>> Yes, I'll fix that. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>> -1) { >>>>>>>>> ... >>>>>>>>> >>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>> mtInternal); >>>>>>>>> ... >>>>>>>>> >>>>>>>>> os_solaris.cpp: 829 >>>>>>>>> The same comment about on-stack allocation as for os_bsd.cpp >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>> >>>>>>>>>> This change addresses the implementation of >>>>>>>>>> init_system_properties_values >>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>> malloc to >>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>> allocation >>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>> pointers as >>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL and >>>>>>>>>> calls to free(). >>>>>>>>>> >>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>> removes >>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>> local array where >>>>>>>>>> possible. >>>>>>>>>> >>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>> set_value copies the strings passed. Thus the memory allocated in >>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>> Most of these >>>>>>>>>> frees were missing. >>>>>>>>>> >>>>>>>>>> This change adds the missing frees. >>>>>>>>>> >>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>> fixed, >>>>>>>>>> too. >>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From dmitry.samersoff at oracle.com Tue Apr 8 22:08:18 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 09 Apr 2014 02:08:18 +0400 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53446D8A.5020207@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> Message-ID: <53447352.9020603@oracle.com> Vladimir, OK. Thank you for clarification. -Dmitry On 2014-04-09 01:43, Vladimir Kozlov wrote: > On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> On 2014-04-09 00:32, Vladimir Kozlov wrote: >> >>> Could you tell when you are planning to backport these changes into >>> 8u20? >> >> This week. Do I need any additional approvals? > > No need for approval but, please, send new [8u20] RFR to hotspot-dev > with links to jbs and jdk9 changeset and say that it applies cleanly (if > it is). I will review it and you can push. > It is to let people know that you backport it. > > Thanks, > Vladimir > >> >> -Dmitry >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Push done. >>>> >>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>> push it to 8u20 >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>> Thanks Dmitry and Vladimir! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Thank you, Dmitry >>>>> >>>>> We need to backport it into 8u20 too. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>> Vladimir, >>>>>> >>>>>> I can push it to RT next week. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Looks good for me! >>>>>>> >>>>>>> +1. >>>>>>> >>>>>>> Dmitry, >>>>>>> >>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>> repo? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>> call to vm_exit_... >>>>>>>>> So I removed the test and return statement. >>>>>>>>> I added the other missing FREEs. >>>>>>>>> >>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>> adapt to that scheme. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() >>>>>>>>> in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>> >>>>>>>>> os_aix.cpp: >>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>> >>>>>>>>> os_bsd.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>> >>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>> >>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>> char *v_colon = ":"; >>>>>>>>> >>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>> >>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>> >>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>> >>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>> ld_library_path); >>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>> ld_library_path */ } >>>>>>>>> ld_library_path = t; >>>>>>>>> } >>>>>>>>> >>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>> without extra copying >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>> take it into account at ll. 495 >>>>>>>>> >>>>>>>>> >>>>>>>>> os_linux.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>> >>>>>>>>> os_solaris.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please have a look at this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>> >>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>> the missing parts in here, below. >>>>>>>>>> >>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>> get along >>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>> >>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>> readability of the code. >>>>>>>>>> >>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>> the >>>>>>>>>> beginning >>>>>>>>>> and do a single allocation for them. >>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>> >>>>>>>>>> You can use >>>>>>>>>> >>>>>>>>>> MAX( >>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>> >>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>> >>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> see my comments inline. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>> >>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>> three >>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>> known size. At >>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>> which may contain several paths. >>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>> two >>>>>>>>>>> buffers are needed. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>> >>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>> it makes >>>>>>>>>>>> code much more readable. >>>>>>>>>>> I'll fix this. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>> >>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>> bytes. I >>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>> large enough >>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>> the >>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>> compiler. >>>>>>>>>>> >>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>> spaces >>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>> allocated >>>>>>>>>>> buffer. >>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>> >>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>> the same comments as above. >>>>>>>>>>>> >>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>> >>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>> code >>>>>>>>>>>> changed >>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>> respect >>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>> variables. >>>>>>>>>>>> >>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>> -1) { >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>> mtInternal); >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>> os_bsd.cpp >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>> init_system_properties_values >>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>> malloc to >>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>> allocation >>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>> pointers as >>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>> and >>>>>>>>>>> calls to free(). >>>>>>>>>>> >>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>> removes >>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>> local array where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>> allocated in >>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>> Most of these >>>>>>>>>>> frees were missing. >>>>>>>>>>> >>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>> >>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>> fixed, >>>>>>>>>>> too. >>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From goetz.lindenmaier at sap.com Wed Apr 9 06:40:52 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 9 Apr 2014 06:40:52 +0000 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53447352.9020603@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <53447352.9020603@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAF4B6@DEWDFEMB12A.global.corp.sap> Vladimir, Dmitry, Thanks for handling this! Sorry I can't help. Best regards, Goetz -----Original Message----- From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] Sent: Mittwoch, 9. April 2014 00:08 To: Vladimir Kozlov; Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() Vladimir, OK. Thank you for clarification. -Dmitry On 2014-04-09 01:43, Vladimir Kozlov wrote: > On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> On 2014-04-09 00:32, Vladimir Kozlov wrote: >> >>> Could you tell when you are planning to backport these changes into >>> 8u20? >> >> This week. Do I need any additional approvals? > > No need for approval but, please, send new [8u20] RFR to hotspot-dev > with links to jbs and jdk9 changeset and say that it applies cleanly (if > it is). I will review it and you can push. > It is to let people know that you backport it. > > Thanks, > Vladimir > >> >> -Dmitry >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Push done. >>>> >>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>> push it to 8u20 >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>> Thanks Dmitry and Vladimir! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Thank you, Dmitry >>>>> >>>>> We need to backport it into 8u20 too. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>> Vladimir, >>>>>> >>>>>> I can push it to RT next week. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Looks good for me! >>>>>>> >>>>>>> +1. >>>>>>> >>>>>>> Dmitry, >>>>>>> >>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>> repo? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>> call to vm_exit_... >>>>>>>>> So I removed the test and return statement. >>>>>>>>> I added the other missing FREEs. >>>>>>>>> >>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>> adapt to that scheme. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() >>>>>>>>> in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>> >>>>>>>>> os_aix.cpp: >>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>> >>>>>>>>> os_bsd.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>> >>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>> >>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>> char *v_colon = ":"; >>>>>>>>> >>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>> >>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>> >>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>> >>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>> ld_library_path); >>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>> ld_library_path */ } >>>>>>>>> ld_library_path = t; >>>>>>>>> } >>>>>>>>> >>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>> without extra copying >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>> take it into account at ll. 495 >>>>>>>>> >>>>>>>>> >>>>>>>>> os_linux.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>> >>>>>>>>> os_solaris.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please have a look at this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>> >>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>> the missing parts in here, below. >>>>>>>>>> >>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>> get along >>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>> >>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>> readability of the code. >>>>>>>>>> >>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>> the >>>>>>>>>> beginning >>>>>>>>>> and do a single allocation for them. >>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>> >>>>>>>>>> You can use >>>>>>>>>> >>>>>>>>>> MAX( >>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>> >>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>> >>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> see my comments inline. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>> >>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>> three >>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>> known size. At >>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>> which may contain several paths. >>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>> two >>>>>>>>>>> buffers are needed. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>> >>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>> it makes >>>>>>>>>>>> code much more readable. >>>>>>>>>>> I'll fix this. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>> >>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>> bytes. I >>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>> large enough >>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>> the >>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>> compiler. >>>>>>>>>>> >>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>> spaces >>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>> allocated >>>>>>>>>>> buffer. >>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>> >>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>> the same comments as above. >>>>>>>>>>>> >>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>> >>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>> code >>>>>>>>>>>> changed >>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>> respect >>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>> variables. >>>>>>>>>>>> >>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>> -1) { >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>> mtInternal); >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>> os_bsd.cpp >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>> init_system_properties_values >>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>> malloc to >>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>> allocation >>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>> pointers as >>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>> and >>>>>>>>>>> calls to free(). >>>>>>>>>>> >>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>> removes >>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>> local array where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>> allocated in >>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>> Most of these >>>>>>>>>>> frees were missing. >>>>>>>>>>> >>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>> >>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>> fixed, >>>>>>>>>>> too. >>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Wed Apr 9 14:53:32 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 09 Apr 2014 18:53:32 +0400 Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53446D8A.5020207@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> Message-ID: <53455EEC.3030900@oracle.com> Hi Everybody, I would like to ask the backport of the changes made for the following bug report into JDK 8 (jdk8u20): Changes applies clearly, without modifications. CR: https://bugs.openjdk.java.net/browse/JDK-8038201 Webrev: http://cr.openjdk.java.net/~dsamersoff/sponsorship/goetz/JDK-8038201/webrev.8u20/ JDK9 changeset http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/bba041a9a030 -Dmitry On 2014-04-09 01:43, Vladimir Kozlov wrote: > On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> On 2014-04-09 00:32, Vladimir Kozlov wrote: >> >>> Could you tell when you are planning to backport these changes into >>> 8u20? >> >> This week. Do I need any additional approvals? > > No need for approval but, please, send new [8u20] RFR to hotspot-dev > with links to jbs and jdk9 changeset and say that it applies cleanly (if > it is). I will review it and you can push. > It is to let people know that you backport it. > > Thanks, > Vladimir > >> >> -Dmitry >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Push done. >>>> >>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>> push it to 8u20 >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>> Thanks Dmitry and Vladimir! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Thank you, Dmitry >>>>> >>>>> We need to backport it into 8u20 too. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>> Vladimir, >>>>>> >>>>>> I can push it to RT next week. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Looks good for me! >>>>>>> >>>>>>> +1. >>>>>>> >>>>>>> Dmitry, >>>>>>> >>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>> repo? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>> call to vm_exit_... >>>>>>>>> So I removed the test and return statement. >>>>>>>>> I added the other missing FREEs. >>>>>>>>> >>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>> adapt to that scheme. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() >>>>>>>>> in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>> >>>>>>>>> os_aix.cpp: >>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>> >>>>>>>>> os_bsd.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>> >>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>> >>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>> char *v_colon = ":"; >>>>>>>>> >>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>> >>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>> >>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>> >>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>> ld_library_path); >>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>> ld_library_path */ } >>>>>>>>> ld_library_path = t; >>>>>>>>> } >>>>>>>>> >>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>> without extra copying >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>> take it into account at ll. 495 >>>>>>>>> >>>>>>>>> >>>>>>>>> os_linux.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>> >>>>>>>>> os_solaris.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please have a look at this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>> >>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>> the missing parts in here, below. >>>>>>>>>> >>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>> get along >>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>> >>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>> readability of the code. >>>>>>>>>> >>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>> the >>>>>>>>>> beginning >>>>>>>>>> and do a single allocation for them. >>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>> >>>>>>>>>> You can use >>>>>>>>>> >>>>>>>>>> MAX( >>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>> >>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>> >>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> see my comments inline. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>> >>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>> three >>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>> known size. At >>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>> which may contain several paths. >>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>> two >>>>>>>>>>> buffers are needed. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>> >>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>> it makes >>>>>>>>>>>> code much more readable. >>>>>>>>>>> I'll fix this. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>> >>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>> bytes. I >>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>> large enough >>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>> the >>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>> compiler. >>>>>>>>>>> >>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>> spaces >>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>> allocated >>>>>>>>>>> buffer. >>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>> >>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>> the same comments as above. >>>>>>>>>>>> >>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>> >>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>> code >>>>>>>>>>>> changed >>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>> respect >>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>> variables. >>>>>>>>>>>> >>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>> -1) { >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>> mtInternal); >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>> os_bsd.cpp >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>> init_system_properties_values >>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>> malloc to >>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>> allocation >>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>> pointers as >>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>> and >>>>>>>>>>> calls to free(). >>>>>>>>>>> >>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>> removes >>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>> local array where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>> allocated in >>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>> Most of these >>>>>>>>>>> frees were missing. >>>>>>>>>>> >>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>> >>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>> fixed, >>>>>>>>>>> too. >>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From roland.westrelin at oracle.com Wed Apr 9 17:18:52 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 9 Apr 2014 19:18:52 +0200 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: <533C34E1.7090801@oracle.com> References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> <533B3174.5060301@oracle.com> <25AA6D2D-A229-4FF1-9CB6-C0C502D108D2@oracle.com> <533C34E1.7090801@oracle.com> Message-ID: <2347D3C4-1383-44F5-B64D-2501FE14212D@oracle.com> Hi Vladimir, > I tried to tell about this during review ;) I thought using (<=StackShadowPages) from 8026775 changes should touch it. Sorry Vladimir. I didn?t realize there could be a problem even before the end of the stack is reached. I should have read 8026775 more carefully. > Can you spend sometime and write down in bug report about all places where we do stack bang and how much pages we bang so we can see whole picture? > > I think we should bang all sequential pages and do the same in all places. Banging StackShadowPages or StackShadowPages+1 is secondary if we do the same in all places. Ready for some headaches? The interpreter: allocates the current frame and then stack bangs all pages at sp+1*page ? sp+StackShadowPages*page included The compiler bangs (before my change): sp + StackShadowPages*page and the next frame_size/page_size pages In the deopt blob we bang: sp (once the compiled frame is popped) +1 page ? sp+(StackShadowPages+1)*page and the next frame_size/page_size pages I talked with Mikael and the reason we bang up to (StackShadowPages+1)*page in the deopt blob is because in the interpreter, banging happens once the frame is set up. So banging up to StackShadowPages*page in the deopt blob with no frame pushed doesn?t bang as far as the interpreter would. Let?s take an example with my change (no banging in the deopt blob) and if the compiler bangs at sp+StackShadowPages*page. I think something like this is possible: Let?s say StackShadowPages=2 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P. The interpreter bangs P+1 and P+2. 2) The interpreter calls a compiled method. The compiled method is entered with SP still in P but right before the boundary with the next page. The compiler bangs P+2. 3) We deoptimize. We pop the frame. SP is in P right before the page boundary. The method has a lot of locals and the interpreter frame size is just below 1 page. After deoptimization SP is in P+1 right before the boundary. 4) We?re at a call, push some arguments and SP moves to P+2 and we call a compiled method. The compiled method bang P+4. P+3 was never touched. Had the compiler banged at P+3 (StackShadowPages+1) in 2), there would be no problem in that example. But then another example with my change and if the compiler bangs at sp+(StackShadowPages+1)*page. Let?s say StackShadowPages=2. 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P but right before the page boundary. The interpreter bangs P+1 and P+2. 2) The interpreter pushes some arguments and we are now in P+1 and calls a compiled method. The compiler bangs P+4. P+3 was never touched. So that doesn?t work either. Wishing we had a whiteboard again? ;-) Maybe the solution is for the compiler to bang at sp + StackShadowPages*page + (interpreter_frame_size % page) and the next interpreter_frame_size/page_size pages. That would mimic what the interpreter does and would work in both examples, above I think. interpreter_frame_size would have to not include what?s on the expression stack of the top frame to be as close as possible to the interpreter behavior. Roland. > > Thanks, > Vladimir > > On 4/2/14 1:46 AM, Roland Westrelin wrote: >>> The question is why you got EXCEPTION_ACCESS_VIOLATION for normal stack bang? May be it is 8026775 again when one page is skipped during banging. Windows requires sequential pages touche. >> >> I wasn?t aware of this requirement on windows. Thanks, Vladimir. >> The interpreter bangs up to and including sp + StackShadowPages while the compiled code, with this change, bangs at sp + StackShadowPages + 1. So a page can be skipped and the requirement that all pages be touched sequentially cannot be guaranteed. So we either have to go back to banging at sp + StackShadowPages for the compiled code or enable the code that I pointed to in the signal on 32 bit. What do you think? >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/14 8:00 AM, Roland Westrelin wrote: >>>> I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within the stack bounds). I noticed this code in the windows signal handler: >>>> >>>> #ifdef _WIN64 >>>> // >>>> // If it's a legal stack address map the entire region in >>>> // >>>> PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; >>>> address addr = (address) exceptionRecord->ExceptionInformation[1]; >>>> if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { >>>> addr = (address)((uintptr_t)addr & >>>> (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); >>>> os::commit_memory((char *)addr, thread->stack_base() - addr, >>>> !ExecMem); >>>> return EXCEPTION_CONTINUE_EXECUTION; >>>> } >>>> else >>>> #endif >>>> >>>> If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? >>>> >>>> Roland. >>>> >> From vladimir.kozlov at oracle.com Wed Apr 9 17:22:00 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Apr 2014 10:22:00 -0700 Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53455EEC.3030900@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <53455EEC.3030900@oracle.com> Message-ID: <534581B8.6020304@oracle.com> Looks good. Thanks, Vladimir On 4/9/14 7:53 AM, Dmitry Samersoff wrote: > Hi Everybody, > > I would like to ask the backport of the changes made for the following > bug report into JDK 8 (jdk8u20): > > Changes applies clearly, without modifications. > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8038201 > > Webrev: > > http://cr.openjdk.java.net/~dsamersoff/sponsorship/goetz/JDK-8038201/webrev.8u20/ > > JDK9 changeset > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/bba041a9a030 > > -Dmitry > > On 2014-04-09 01:43, Vladimir Kozlov wrote: >> On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >>> Vladimir, >>> >>> On 2014-04-09 00:32, Vladimir Kozlov wrote: >>> >>>> Could you tell when you are planning to backport these changes into >>>> 8u20? >>> >>> This week. Do I need any additional approvals? >> >> No need for approval but, please, send new [8u20] RFR to hotspot-dev >> with links to jbs and jdk9 changeset and say that it applies cleanly (if >> it is). I will review it and you can push. >> It is to let people know that you backport it. >> >> Thanks, >> Vladimir >> >>> >>> -Dmitry >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>>> Goetz, >>>>> >>>>> Push done. >>>>> >>>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>>> push it to 8u20 >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>>> Thanks Dmitry and Vladimir! >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>> in init_system_properties_values() >>>>>> >>>>>> Thank you, Dmitry >>>>>> >>>>>> We need to backport it into 8u20 too. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>>> Vladimir, >>>>>>> >>>>>>> I can push it to RT next week. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Looks good for me! >>>>>>>> >>>>>>>> +1. >>>>>>>> >>>>>>>> Dmitry, >>>>>>>> >>>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>>> repo? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>>> call to vm_exit_... >>>>>>>>>> So I removed the test and return statement. >>>>>>>>>> I added the other missing FREEs. >>>>>>>>>> >>>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>>> adapt to that scheme. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>> malloc() >>>>>>>>>> in init_system_properties_values() >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>>> >>>>>>>>>> os_aix.cpp: >>>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>>> >>>>>>>>>> os_bsd.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>>> >>>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>>> >>>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>>> char *v_colon = ":"; >>>>>>>>>> >>>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>>> >>>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>>> >>>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>>> >>>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>>> ld_library_path); >>>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>>> ld_library_path */ } >>>>>>>>>> ld_library_path = t; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>>> without extra copying >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>>> take it into account at ll. 495 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> os_linux.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please have a look at this new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>>> the missing parts in here, below. >>>>>>>>>>> >>>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>>> get along >>>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>>> >>>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>>> readability of the code. >>>>>>>>>>> >>>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>>> the >>>>>>>>>>> beginning >>>>>>>>>>> and do a single allocation for them. >>>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Goetz, >>>>>>>>>>> >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>>> >>>>>>>>>>> You can use >>>>>>>>>>> >>>>>>>>>>> MAX( >>>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>>> >>>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>>> >>>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> see my comments inline. >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>>> >>>>>>>>>>>>> Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>>> >>>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>>> three >>>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>>> known size. At >>>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>>> which may contain several paths. >>>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>>> two >>>>>>>>>>>> buffers are needed. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>>> >>>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>>> it makes >>>>>>>>>>>>> code much more readable. >>>>>>>>>>>> I'll fix this. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>>> >>>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>>> bytes. I >>>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>>> large enough >>>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>>> the >>>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>>> compiler. >>>>>>>>>>>> >>>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>>> spaces >>>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>>> allocated >>>>>>>>>>>> buffer. >>>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>>> >>>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>>> the same comments as above. >>>>>>>>>>>>> >>>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>>> >>>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>>> code >>>>>>>>>>>>> changed >>>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>>> respect >>>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>>> variables. >>>>>>>>>>>>> >>>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>>> -1) { >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>>> mtInternal); >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>>> os_bsd.cpp >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>>> init_system_properties_values >>>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>>> malloc to >>>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>>> allocation >>>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>>> pointers as >>>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>>> and >>>>>>>>>>>> calls to free(). >>>>>>>>>>>> >>>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>>> removes >>>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>>> local array where >>>>>>>>>>>> possible. >>>>>>>>>>>> >>>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>>> allocated in >>>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>>> Most of these >>>>>>>>>>>> frees were missing. >>>>>>>>>>>> >>>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>>> >>>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>>> fixed, >>>>>>>>>>>> too. >>>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From vladimir.kozlov at oracle.com Wed Apr 9 22:01:38 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Apr 2014 15:01:38 -0700 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: <2347D3C4-1383-44F5-B64D-2501FE14212D@oracle.com> References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> <533B3174.5060301@oracle.com> <25AA6D2D-A229-4FF1-9CB6-C0C502D108D2@oracle.com> <533C34E1.7090801@oracle.com> <2347D3C4-1383-44F5-B64D-2501FE14212D@oracle.com> Message-ID: <5345C342.4040704@oracle.com> On 4/9/14 10:18 AM, Roland Westrelin wrote: > Hi Vladimir, > >> I tried to tell about this during review ;) I thought using (<=StackShadowPages) from 8026775 changes should touch it. > > Sorry Vladimir. I didn?t realize there could be a problem even before the end of the stack is reached. I should have read 8026775 more carefully. > >> Can you spend sometime and write down in bug report about all places where we do stack bang and how much pages we bang so we can see whole picture? >> >> I think we should bang all sequential pages and do the same in all places. Banging StackShadowPages or StackShadowPages+1 is secondary if we do the same in all places. > > Ready for some headaches? > > The interpreter: allocates the current frame and then stack bangs all pages at sp+1*page ? sp+StackShadowPages*page included > The compiler bangs (before my change): sp + StackShadowPages*page and the next frame_size/page_size pages > In the deopt blob we bang: sp (once the compiled frame is popped) +1 page ? sp+(StackShadowPages+1)*page and the next frame_size/page_size pages > > I talked with Mikael and the reason we bang up to (StackShadowPages+1)*page in the deopt blob is because in the interpreter, banging happens once the frame is set up. So banging up to StackShadowPages*page in the deopt blob with no frame pushed doesn?t bang as far as the interpreter would. So far I am following :) > > Let?s take an example with my change (no banging in the deopt blob) and if the compiler bangs at sp+StackShadowPages*page. I think something like this is possible: > Let?s say StackShadowPages=2 > > 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P. The interpreter bangs P+1 and P+2. Do you mean when the frame is small we stay on the same page after the frame is allocated? Okay. > 2) The interpreter calls a compiled method. The compiled method is entered with SP still in P but right before the boundary with the next page. The compiler bangs P+2. Could you remind me about your change? Does compiled code bangs all range from min(interpr_frame_size, comp_frame_size) to max(interpr_frame_size, comp_frame_size) plus StackShadowPages? Or only (max + StackShadowPages)? > 3) We deoptimize. We pop the frame. SP is in P right before the page boundary. The method has a lot of locals and the interpreter frame size is just below 1 page. After deoptimization SP is in P+1 right before the boundary. So SP is the same as on entry to the compiled method after the frame pop? Do we touch all stack slots when we reconstruct Interpreter frame during deoptimization? Asking for a case when last slots are in next page and we don't touch it. > 4) We?re at a call, push some arguments and SP moves to P+2 and we call a compiled method. The compiled method bang P+4. P+3 was never touched. Method's max_stack should take into account the space for output arguments. It need to be taking into account when we bang in compiled code. In 2) compiled code should have bang p+2 and p+3. > > Had the compiler banged at P+3 (StackShadowPages+1) in 2), there would be no problem in that example. But then another example with my change and if the compiler bangs at sp+(StackShadowPages+1)*page. Let?s say StackShadowPages=2. > > 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P but right before the page boundary. The interpreter bangs P+1 and P+2. > 2) The interpreter pushes some arguments and we are now in P+1 and calls a compiled method. The compiler bangs P+4. P+3 was never touched. > > So that doesn?t work either. > > Wishing we had a whiteboard again? ;-) Yes and yes! > > Maybe the solution is for the compiler to bang at sp + StackShadowPages*page + (interpreter_frame_size % page) and the next interpreter_frame_size/page_size pages. That would mimic what the interpreter does and would work in both examples, above I think. interpreter_frame_size would have to not include what?s on the expression stack of the top frame to be as close as possible to the interpreter behavior. I don't see how you can determine "next interpreter_frame_size/page_size pages" As I said before if compiled code takes into account max stack size then first solution should work, I think. Thanks, Vladimir > > Roland. > > >> >> Thanks, >> Vladimir >> >> On 4/2/14 1:46 AM, Roland Westrelin wrote: >>>> The question is why you got EXCEPTION_ACCESS_VIOLATION for normal stack bang? May be it is 8026775 again when one page is skipped during banging. Windows requires sequential pages touche. >>> >>> I wasn?t aware of this requirement on windows. Thanks, Vladimir. >>> The interpreter bangs up to and including sp + StackShadowPages while the compiled code, with this change, bangs at sp + StackShadowPages + 1. So a page can be skipped and the requirement that all pages be touched sequentially cannot be guaranteed. So we either have to go back to banging at sp + StackShadowPages for the compiled code or enable the code that I pointed to in the signal on 32 bit. What do you think? >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/1/14 8:00 AM, Roland Westrelin wrote: >>>>> I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within the stack bounds). I noticed this code in the windows signal handler: >>>>> >>>>> #ifdef _WIN64 >>>>> // >>>>> // If it's a legal stack address map the entire region in >>>>> // >>>>> PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; >>>>> address addr = (address) exceptionRecord->ExceptionInformation[1]; >>>>> if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { >>>>> addr = (address)((uintptr_t)addr & >>>>> (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); >>>>> os::commit_memory((char *)addr, thread->stack_base() - addr, >>>>> !ExecMem); >>>>> return EXCEPTION_CONTINUE_EXECUTION; >>>>> } >>>>> else >>>>> #endif >>>>> >>>>> If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? >>>>> >>>>> Roland. >>>>> >>> > From vladimir.kozlov at oracle.com Wed Apr 9 22:53:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Apr 2014 15:53:37 -0700 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAF4B6@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <53447352.9020603@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAF4B6@DEWDFEMB12A.global.corp.sap> Message-ID: <5345CF71.8070303@oracle.com> Hi Goetz, You can help :) When Dmitry push the patch into jdk8u/hs-dev can you build and test from it on your platforms (ppc64)? If everything is fine I will do the final merge into ppc-aix-port/stage and we will freeze it. thanks, Vladimir On 4/8/14 11:40 PM, Lindenmaier, Goetz wrote: > Vladimir, Dmitry, > > Thanks for handling this! > Sorry I can't help. > > Best regards, > Goetz > > -----Original Message----- > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > Sent: Mittwoch, 9. April 2014 00:08 > To: Vladimir Kozlov; Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() > > Vladimir, > > OK. Thank you for clarification. > > -Dmitry > > On 2014-04-09 01:43, Vladimir Kozlov wrote: >> On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >>> Vladimir, >>> >>> On 2014-04-09 00:32, Vladimir Kozlov wrote: >>> >>>> Could you tell when you are planning to backport these changes into >>>> 8u20? >>> >>> This week. Do I need any additional approvals? >> >> No need for approval but, please, send new [8u20] RFR to hotspot-dev >> with links to jbs and jdk9 changeset and say that it applies cleanly (if >> it is). I will review it and you can push. >> It is to let people know that you backport it. >> >> Thanks, >> Vladimir >> >>> >>> -Dmitry >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>>> Goetz, >>>>> >>>>> Push done. >>>>> >>>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>>> push it to 8u20 >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>>> Thanks Dmitry and Vladimir! >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>> in init_system_properties_values() >>>>>> >>>>>> Thank you, Dmitry >>>>>> >>>>>> We need to backport it into 8u20 too. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>>> Vladimir, >>>>>>> >>>>>>> I can push it to RT next week. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Looks good for me! >>>>>>>> >>>>>>>> +1. >>>>>>>> >>>>>>>> Dmitry, >>>>>>>> >>>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>>> repo? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>>> call to vm_exit_... >>>>>>>>>> So I removed the test and return statement. >>>>>>>>>> I added the other missing FREEs. >>>>>>>>>> >>>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>>> adapt to that scheme. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>> malloc() >>>>>>>>>> in init_system_properties_values() >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>>> >>>>>>>>>> os_aix.cpp: >>>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>>> >>>>>>>>>> os_bsd.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>>> >>>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>>> >>>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>>> char *v_colon = ":"; >>>>>>>>>> >>>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>>> >>>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>>> >>>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>>> >>>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>>> ld_library_path); >>>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>>> ld_library_path */ } >>>>>>>>>> ld_library_path = t; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>>> without extra copying >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>>> take it into account at ll. 495 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> os_linux.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please have a look at this new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>>> the missing parts in here, below. >>>>>>>>>>> >>>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>>> get along >>>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>>> >>>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>>> readability of the code. >>>>>>>>>>> >>>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>>> the >>>>>>>>>>> beginning >>>>>>>>>>> and do a single allocation for them. >>>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Goetz, >>>>>>>>>>> >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>>> >>>>>>>>>>> You can use >>>>>>>>>>> >>>>>>>>>>> MAX( >>>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>>> >>>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>>> >>>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> see my comments inline. >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>>> >>>>>>>>>>>>> Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>>> >>>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>>> three >>>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>>> known size. At >>>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>>> which may contain several paths. >>>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>>> two >>>>>>>>>>>> buffers are needed. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>>> >>>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>>> it makes >>>>>>>>>>>>> code much more readable. >>>>>>>>>>>> I'll fix this. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>>> >>>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>>> bytes. I >>>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>>> large enough >>>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>>> the >>>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>>> compiler. >>>>>>>>>>>> >>>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>>> spaces >>>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>>> allocated >>>>>>>>>>>> buffer. >>>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>>> >>>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>>> the same comments as above. >>>>>>>>>>>>> >>>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>>> >>>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>>> code >>>>>>>>>>>>> changed >>>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>>> respect >>>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>>> variables. >>>>>>>>>>>>> >>>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>>> -1) { >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>>> mtInternal); >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>>> os_bsd.cpp >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>>> init_system_properties_values >>>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>>> malloc to >>>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>>> allocation >>>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>>> pointers as >>>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>>> and >>>>>>>>>>>> calls to free(). >>>>>>>>>>>> >>>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>>> removes >>>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>>> local array where >>>>>>>>>>>> possible. >>>>>>>>>>>> >>>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>>> allocated in >>>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>>> Most of these >>>>>>>>>>>> frees were missing. >>>>>>>>>>>> >>>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>>> >>>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>>> fixed, >>>>>>>>>>>> too. >>>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From christian.thalinger at oracle.com Thu Apr 10 02:31:42 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Apr 2014 16:31:42 -1000 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: <5345C342.4040704@oracle.com> References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> <533B3174.5060301@oracle.com> <25AA6D2D-A229-4FF1-9CB6-C0C502D108D2@oracle.com> <533C34E1.7090801@oracle.com> <2347D3C4-1383-44F5-B64D-2501FE14212D@oracle.com> <5345C342.4040704@oracle.com> Message-ID: <3E7ACC19-8B50-4DB2-8A07-7B05F4455EE8@oracle.com> Having dealt with the other bug that Mikael finally untangled and fixed it seems to be a better (safer) solution to do the commit-memory-in-signal-handler thing on Windows. As far as I understand it this is not a problem on non-Windows systems and on Windows it would happen very rarely namely the odd corner cases that Roland listed. Right? On Apr 9, 2014, at 12:01 PM, Vladimir Kozlov wrote: > On 4/9/14 10:18 AM, Roland Westrelin wrote: >> Hi Vladimir, >> >>> I tried to tell about this during review ;) I thought using (<=StackShadowPages) from 8026775 changes should touch it. >> >> Sorry Vladimir. I didn?t realize there could be a problem even before the end of the stack is reached. I should have read 8026775 more carefully. >> >>> Can you spend sometime and write down in bug report about all places where we do stack bang and how much pages we bang so we can see whole picture? >>> >>> I think we should bang all sequential pages and do the same in all places. Banging StackShadowPages or StackShadowPages+1 is secondary if we do the same in all places. >> >> Ready for some headaches? >> >> The interpreter: allocates the current frame and then stack bangs all pages at sp+1*page ? sp+StackShadowPages*page included >> The compiler bangs (before my change): sp + StackShadowPages*page and the next frame_size/page_size pages >> In the deopt blob we bang: sp (once the compiled frame is popped) +1 page ? sp+(StackShadowPages+1)*page and the next frame_size/page_size pages >> >> I talked with Mikael and the reason we bang up to (StackShadowPages+1)*page in the deopt blob is because in the interpreter, banging happens once the frame is set up. So banging up to StackShadowPages*page in the deopt blob with no frame pushed doesn?t bang as far as the interpreter would. > > So far I am following :) > >> >> Let?s take an example with my change (no banging in the deopt blob) and if the compiler bangs at sp+StackShadowPages*page. I think something like this is possible: >> Let?s say StackShadowPages=2 >> >> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P. The interpreter bangs P+1 and P+2. > > Do you mean when the frame is small we stay on the same page after the frame is allocated? Okay. > >> 2) The interpreter calls a compiled method. The compiled method is entered with SP still in P but right before the boundary with the next page. The compiler bangs P+2. > > Could you remind me about your change? Does compiled code bangs all range from min(interpr_frame_size, comp_frame_size) to max(interpr_frame_size, comp_frame_size) plus StackShadowPages? Or only (max + StackShadowPages)? > >> 3) We deoptimize. We pop the frame. SP is in P right before the page boundary. The method has a lot of locals and the interpreter frame size is just below 1 page. After deoptimization SP is in P+1 right before the boundary. > > So SP is the same as on entry to the compiled method after the frame pop? > Do we touch all stack slots when we reconstruct Interpreter frame during deoptimization? Asking for a case when last slots are in next page and we don't touch it. > >> 4) We?re at a call, push some arguments and SP moves to P+2 and we call a compiled method. The compiled method bang P+4. P+3 was never touched. > > Method's max_stack should take into account the space for output arguments. It need to be taking into account when we bang in compiled code. In 2) compiled code should have bang p+2 and p+3. > >> >> Had the compiler banged at P+3 (StackShadowPages+1) in 2), there would be no problem in that example. But then another example with my change and if the compiler bangs at sp+(StackShadowPages+1)*page. Let?s say StackShadowPages=2. >> >> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P but right before the page boundary. The interpreter bangs P+1 and P+2. >> 2) The interpreter pushes some arguments and we are now in P+1 and calls a compiled method. The compiler bangs P+4. P+3 was never touched. >> >> So that doesn?t work either. >> >> Wishing we had a whiteboard again? ;-) > > Yes and yes! > >> >> Maybe the solution is for the compiler to bang at sp + StackShadowPages*page + (interpreter_frame_size % page) and the next interpreter_frame_size/page_size pages. That would mimic what the interpreter does and would work in both examples, above I think. interpreter_frame_size would have to not include what?s on the expression stack of the top frame to be as close as possible to the interpreter behavior. > > I don't see how you can determine "next interpreter_frame_size/page_size pages" > > As I said before if compiled code takes into account max stack size then first solution should work, I think. > > Thanks, > Vladimir > > >> >> Roland. >> >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/2/14 1:46 AM, Roland Westrelin wrote: >>>>> The question is why you got EXCEPTION_ACCESS_VIOLATION for normal stack bang? May be it is 8026775 again when one page is skipped during banging. Windows requires sequential pages touche. >>>> >>>> I wasn?t aware of this requirement on windows. Thanks, Vladimir. >>>> The interpreter bangs up to and including sp + StackShadowPages while the compiled code, with this change, bangs at sp + StackShadowPages + 1. So a page can be skipped and the requirement that all pages be touched sequentially cannot be guaranteed. So we either have to go back to banging at sp + StackShadowPages for the compiled code or enable the code that I pointed to in the signal on 32 bit. What do you think? >>>> >>>> Roland. >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 4/1/14 8:00 AM, Roland Westrelin wrote: >>>>>> I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within the stack bounds). I noticed this code in the windows signal handler: >>>>>> >>>>>> #ifdef _WIN64 >>>>>> // >>>>>> // If it's a legal stack address map the entire region in >>>>>> // >>>>>> PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; >>>>>> address addr = (address) exceptionRecord->ExceptionInformation[1]; >>>>>> if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { >>>>>> addr = (address)((uintptr_t)addr & >>>>>> (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); >>>>>> os::commit_memory((char *)addr, thread->stack_base() - addr, >>>>>> !ExecMem); >>>>>> return EXCEPTION_CONTINUE_EXECUTION; >>>>>> } >>>>>> else >>>>>> #endif >>>>>> >>>>>> If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? >>>>>> >>>>>> Roland. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Apr 10 07:54:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Apr 2014 00:54:35 -0700 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: <3E7ACC19-8B50-4DB2-8A07-7B05F4455EE8@oracle.com> References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> <533B3174.5060301@oracle.com> <25AA6D2D-A229-4FF1-9CB6-C0C502D108D2@oracle.com> <533C34E1.7090801@oracle.com> <2347D3C4-1383-44F5-B64D-2501FE14212D@oracle.com> <5345C342.4040704@oracle.com> <3E7ACC19-8B50-4DB2-8A07-7B05F4455EE8@oracle.com> Message-ID: <53464E3B.80501@oracle.com> On 4/9/14 7:31 PM, Christian Thalinger wrote: > Having dealt with the other bug that Mikael finally untangled and fixed it seems to be a better (safer) solution to do > the commit-memory-in-signal-handler thing on Windows. As far as I understand it this is not a problem on non-Windows > systems and on Windows it would happen very rarely namely the odd corner cases that Roland listed. Right? It is not a problem on non-Windows only now. Nobody guarantee that other platforms will not add such restriction later. I am fine with adding commit-memory-in-signal-handler change after we fix current issue with Roland changes. Thanks, Vladimir > > On Apr 9, 2014, at 12:01 PM, Vladimir Kozlov > wrote: > >> On 4/9/14 10:18 AM, Roland Westrelin wrote: >>> Hi Vladimir, >>> >>>> I tried to tell about this during review ;) I thought using (<=StackShadowPages) from 8026775 changes should touch it. >>> >>> Sorry Vladimir. I didn?t realize there could be a problem even before the end of the stack is reached. I should have >>> read 8026775 more carefully. >>> >>>> Can you spend sometime and write down in bug report about all places where we do stack bang and how much pages we >>>> bang so we can see whole picture? >>>> >>>> I think we should bang all sequential pages and do the same in all places. Banging StackShadowPages or >>>> StackShadowPages+1 is secondary if we do the same in all places. >>> >>> Ready for some headaches? >>> >>> The interpreter: allocates the current frame and then stack bangs all pages at sp+1*page ? sp+StackShadowPages*page >>> included >>> The compiler bangs (before my change): sp + StackShadowPages*page and the next frame_size/page_size pages >>> In the deopt blob we bang: sp (once the compiled frame is popped) +1 page ? sp+(StackShadowPages+1)*page and the next >>> frame_size/page_size pages >>> >>> I talked with Mikael and the reason we bang up to (StackShadowPages+1)*page in the deopt blob is because in the >>> interpreter, banging happens once the frame is set up. So banging up to StackShadowPages*page in the deopt blob with >>> no frame pushed doesn?t bang as far as the interpreter would. >> >> So far I am following :) >> >>> >>> Let?s take an example with my change (no banging in the deopt blob) and if the compiler bangs at >>> sp+StackShadowPages*page. I think something like this is possible: >>> Let?s say StackShadowPages=2 >>> >>> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P. The interpreter >>> bangs P+1 and P+2. >> >> Do you mean when the frame is small we stay on the same page after the frame is allocated? Okay. >> >>> 2) The interpreter calls a compiled method. The compiled method is entered with SP still in P but right before the >>> boundary with the next page. The compiler bangs P+2. >> >> Could you remind me about your change? Does compiled code bangs all range from min(interpr_frame_size, >> comp_frame_size) to max(interpr_frame_size, comp_frame_size) plus StackShadowPages? Or only (max + StackShadowPages)? >> >>> 3) We deoptimize. We pop the frame. SP is in P right before the page boundary. The method has a lot of locals and the >>> interpreter frame size is just below 1 page. After deoptimization SP is in P+1 right before the boundary. >> >> So SP is the same as on entry to the compiled method after the frame pop? >> Do we touch all stack slots when we reconstruct Interpreter frame during deoptimization? Asking for a case when last >> slots are in next page and we don't touch it. >> >>> 4) We?re at a call, push some arguments and SP moves to P+2 and we call a compiled method. The compiled method bang >>> P+4. P+3 was never touched. >> >> Method's max_stack should take into account the space for output arguments. It need to be taking into account when we >> bang in compiled code. In 2) compiled code should have bang p+2 and p+3. >> >>> >>> Had the compiler banged at P+3 (StackShadowPages+1) in 2), there would be no problem in that example. But then >>> another example with my change and if the compiler bangs at sp+(StackShadowPages+1)*page. Let?s say StackShadowPages=2. >>> >>> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P but right before the >>> page boundary. The interpreter bangs P+1 and P+2. >>> 2) The interpreter pushes some arguments and we are now in P+1 and calls a compiled method. The compiler bangs P+4. >>> P+3 was never touched. >>> >>> So that doesn?t work either. >>> >>> Wishing we had a whiteboard again? ;-) >> >> Yes and yes! >> >>> >>> Maybe the solution is for the compiler to bang at sp + StackShadowPages*page + (interpreter_frame_size % page) and >>> the next interpreter_frame_size/page_size pages. That would mimic what the interpreter does and would work in both >>> examples, above I think. interpreter_frame_size would have to not include what?s on the expression stack of the top >>> frame to be as close as possible to the interpreter behavior. >> >> I don't see how you can determine "next interpreter_frame_size/page_size pages" >> >> As I said before if compiled code takes into account max stack size then first solution should work, I think. >> >> Thanks, >> Vladimir >> >> >>> >>> Roland. >>> >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/2/14 1:46 AM, Roland Westrelin wrote: >>>>>> The question is why you got EXCEPTION_ACCESS_VIOLATION for normal stack bang? May be it is 8026775 again when one >>>>>> page is skipped during banging. Windows requires sequential pages touche. >>>>> >>>>> I wasn?t aware of this requirement on windows. Thanks, Vladimir. >>>>> The interpreter bangs up to and including sp + StackShadowPages while the compiled code, with this change, bangs at >>>>> sp + StackShadowPages + 1. So a page can be skipped and the requirement that all pages be touched sequentially >>>>> cannot be guaranteed. So we either have to go back to banging at sp + StackShadowPages for the compiled code or >>>>> enable the code that I pointed to in the signal on 32 bit. What do you think? >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 4/1/14 8:00 AM, Roland Westrelin wrote: >>>>>>> I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging >>>>>>> instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within >>>>>>> the stack bounds). I noticed this code in the windows signal handler: >>>>>>> >>>>>>> #ifdef _WIN64 >>>>>>> // >>>>>>> // If it's a legal stack address map the entire region in >>>>>>> // >>>>>>> PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; >>>>>>> address addr = (address) exceptionRecord->ExceptionInformation[1]; >>>>>>> if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { >>>>>>> addr = (address)((uintptr_t)addr & >>>>>>> (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); >>>>>>> os::commit_memory((char *)addr, thread->stack_base() - addr, >>>>>>> !ExecMem); >>>>>>> return EXCEPTION_CONTINUE_EXECUTION; >>>>>>> } >>>>>>> else >>>>>>> #endif >>>>>>> >>>>>>> If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? >>>>>>> >>>>>>> Roland. > From roland.westrelin at oracle.com Thu Apr 10 08:26:59 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 10 Apr 2014 10:26:59 +0200 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: <5345C342.4040704@oracle.com> References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> <533B3174.5060301@oracle.com> <25AA6D2D-A229-4FF1-9CB6-C0C502D108D2@oracle.com> <533C34E1.7090801@oracle.com> <2347D3C4-1383-44F5-B64D-2501FE14212D@oracle.com> <5345C342.4040704@oracle.com> Message-ID: <73613160-EF81-41E9-8112-0E078D6BB758@oracle.com> Hi Vladimir, >>> I tried to tell about this during review ;) I thought using (<=StackShadowPages) from 8026775 changes should touch it. >> >> Sorry Vladimir. I didn?t realize there could be a problem even before the end of the stack is reached. I should have read 8026775 more carefully. >> >>> Can you spend sometime and write down in bug report about all places where we do stack bang and how much pages we bang so we can see whole picture? >>> >>> I think we should bang all sequential pages and do the same in all places. Banging StackShadowPages or StackShadowPages+1 is secondary if we do the same in all places. >> >> Ready for some headaches? >> >> The interpreter: allocates the current frame and then stack bangs all pages at sp+1*page ? sp+StackShadowPages*page included >> The compiler bangs (before my change): sp + StackShadowPages*page and the next frame_size/page_size pages >> In the deopt blob we bang: sp (once the compiled frame is popped) +1 page ? sp+(StackShadowPages+1)*page and the next frame_size/page_size pages >> >> I talked with Mikael and the reason we bang up to (StackShadowPages+1)*page in the deopt blob is because in the interpreter, banging happens once the frame is set up. So banging up to StackShadowPages*page in the deopt blob with no frame pushed doesn?t bang as far as the interpreter would. > > So far I am following :) > >> >> Let?s take an example with my change (no banging in the deopt blob) and if the compiler bangs at sp+StackShadowPages*page. I think something like this is possible: >> Let?s say StackShadowPages=2 >> >> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P. The interpreter bangs P+1 and P+2. > > Do you mean when the frame is small we stay on the same page after the frame is allocated? Okay. Yes. > >> 2) The interpreter calls a compiled method. The compiled method is entered with SP still in P but right before the boundary with the next page. The compiler bangs P+2. > > Could you remind me about your change? Does compiled code bangs all range from min(interpr_frame_size, comp_frame_size) to max(interpr_frame_size, comp_frame_size) plus StackShadowPages? Or only (max + StackShadowPages)? It bangs pages at sp + StackShadowPages*page_size and the next max(interpr_frame_size, comp_frame_size)/page_size pages if any. Before my change, the compiled code banged at sp + StackShadowPages*page_size and the next comp_frame_size/page_size pages if any > >> 3) We deoptimize. We pop the frame. SP is in P right before the page boundary. The method has a lot of locals and the interpreter frame size is just below 1 page. After deoptimization SP is in P+1 right before the boundary. > > So SP is the same as on entry to the compiled method after the frame pop? Yes. > Do we touch all stack slots when we reconstruct Interpreter frame during deoptimization? Asking for a case when last slots are in next page and we don't touch it. I assume we do. > >> 4) We?re at a call, push some arguments and SP moves to P+2 and we call a compiled method. The compiled method bang P+4. P+3 was never touched. > > Method's max_stack should take into account the space for output arguments. It need to be taking into account when we bang in compiled code. In 2) compiled code should have bang p+2 and p+3. Ok. That would work indeed. >> >> Had the compiler banged at P+3 (StackShadowPages+1) in 2), there would be no problem in that example. But then another example with my change and if the compiler bangs at sp+(StackShadowPages+1)*page. Let?s say StackShadowPages=2. >> >> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P but right before the page boundary. The interpreter bangs P+1 and P+2. >> 2) The interpreter pushes some arguments and we are now in P+1 and calls a compiled method. The compiler bangs P+4. P+3 was never touched. >> >> So that doesn?t work either. >> >> Wishing we had a whiteboard again? ;-) > > Yes and yes! > >> >> Maybe the solution is for the compiler to bang at sp + StackShadowPages*page + (interpreter_frame_size % page) and the next interpreter_frame_size/page_size pages. That would mimic what the interpreter does and would work in both examples, above I think. interpreter_frame_size would have to not include what?s on the expression stack of the top frame to be as close as possible to the interpreter behavior. > > I don't see how you can determine "next interpreter_frame_size/page_size pages" > > As I said before if compiled code takes into account max stack size then first solution should work, I think. Let me try that. Thanks! Roland. > > Thanks, > Vladimir > > >> >> Roland. >> >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/2/14 1:46 AM, Roland Westrelin wrote: >>>>> The question is why you got EXCEPTION_ACCESS_VIOLATION for normal stack bang? May be it is 8026775 again when one page is skipped during banging. Windows requires sequential pages touche. >>>> >>>> I wasn?t aware of this requirement on windows. Thanks, Vladimir. >>>> The interpreter bangs up to and including sp + StackShadowPages while the compiled code, with this change, bangs at sp + StackShadowPages + 1. So a page can be skipped and the requirement that all pages be touched sequentially cannot be guaranteed. So we either have to go back to banging at sp + StackShadowPages for the compiled code or enable the code that I pointed to in the signal on 32 bit. What do you think? >>>> >>>> Roland. >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 4/1/14 8:00 AM, Roland Westrelin wrote: >>>>>> I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within the stack bounds). I noticed this code in the windows signal handler: >>>>>> >>>>>> #ifdef _WIN64 >>>>>> // >>>>>> // If it's a legal stack address map the entire region in >>>>>> // >>>>>> PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; >>>>>> address addr = (address) exceptionRecord->ExceptionInformation[1]; >>>>>> if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { >>>>>> addr = (address)((uintptr_t)addr & >>>>>> (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); >>>>>> os::commit_memory((char *)addr, thread->stack_base() - addr, >>>>>> !ExecMem); >>>>>> return EXCEPTION_CONTINUE_EXECUTION; >>>>>> } >>>>>> else >>>>>> #endif >>>>>> >>>>>> If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? >>>>>> >>>>>> Roland. From goetz.lindenmaier at sap.com Thu Apr 10 09:06:26 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 10 Apr 2014 09:06:26 +0000 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <5345CF71.8070303@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <53447352.9020603@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAF4B6@DEWDFEMB12A.global.corp.sap> <5345CF71.8070303@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAF94A@DEWDFEMB12A.global.corp.sap> Sure, I'll run a build and tests with it. I can also do this with the webrev he might mail around. Also, you can always see daily test results of builds of a lot of repositories on http://cr.openjdk.java.net/~simonis/ppc-aix-port/ Where we do full builds of: ppc-aix-port/jdk7u weekly jdk8u/jdk8u-dev daily jdk9/dev daily And daily hotspot-only builds of jdk9/hs jdk9/hs-comp jdk9/hs-gc jdk9/hs-rt jdk9/hs-emb jdk8u/hs-dev Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Donnerstag, 10. April 2014 00:54 To: Lindenmaier, Goetz; Dmitry Samersoff; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() Hi Goetz, You can help :) When Dmitry push the patch into jdk8u/hs-dev can you build and test from it on your platforms (ppc64)? If everything is fine I will do the final merge into ppc-aix-port/stage and we will freeze it. thanks, Vladimir On 4/8/14 11:40 PM, Lindenmaier, Goetz wrote: > Vladimir, Dmitry, > > Thanks for handling this! > Sorry I can't help. > > Best regards, > Goetz > > -----Original Message----- > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > Sent: Mittwoch, 9. April 2014 00:08 > To: Vladimir Kozlov; Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() > > Vladimir, > > OK. Thank you for clarification. > > -Dmitry > > On 2014-04-09 01:43, Vladimir Kozlov wrote: >> On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >>> Vladimir, >>> >>> On 2014-04-09 00:32, Vladimir Kozlov wrote: >>> >>>> Could you tell when you are planning to backport these changes into >>>> 8u20? >>> >>> This week. Do I need any additional approvals? >> >> No need for approval but, please, send new [8u20] RFR to hotspot-dev >> with links to jbs and jdk9 changeset and say that it applies cleanly (if >> it is). I will review it and you can push. >> It is to let people know that you backport it. >> >> Thanks, >> Vladimir >> >>> >>> -Dmitry >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>>> Goetz, >>>>> >>>>> Push done. >>>>> >>>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>>> push it to 8u20 >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>>> Thanks Dmitry and Vladimir! >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>> in init_system_properties_values() >>>>>> >>>>>> Thank you, Dmitry >>>>>> >>>>>> We need to backport it into 8u20 too. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>>> Vladimir, >>>>>>> >>>>>>> I can push it to RT next week. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Looks good for me! >>>>>>>> >>>>>>>> +1. >>>>>>>> >>>>>>>> Dmitry, >>>>>>>> >>>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>>> repo? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>>> call to vm_exit_... >>>>>>>>>> So I removed the test and return statement. >>>>>>>>>> I added the other missing FREEs. >>>>>>>>>> >>>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>>> adapt to that scheme. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>> malloc() >>>>>>>>>> in init_system_properties_values() >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>>> >>>>>>>>>> os_aix.cpp: >>>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>>> >>>>>>>>>> os_bsd.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>>> >>>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>>> >>>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>>> char *v_colon = ":"; >>>>>>>>>> >>>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>>> >>>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>>> >>>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>>> >>>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>>> ld_library_path); >>>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>>> ld_library_path */ } >>>>>>>>>> ld_library_path = t; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>>> without extra copying >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>>> take it into account at ll. 495 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> os_linux.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please have a look at this new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>>> the missing parts in here, below. >>>>>>>>>>> >>>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>>> get along >>>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>>> >>>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>>> readability of the code. >>>>>>>>>>> >>>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>>> the >>>>>>>>>>> beginning >>>>>>>>>>> and do a single allocation for them. >>>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Goetz, >>>>>>>>>>> >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>>> >>>>>>>>>>> You can use >>>>>>>>>>> >>>>>>>>>>> MAX( >>>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>>> >>>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>>> >>>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> see my comments inline. >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>>> >>>>>>>>>>>>> Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>>> >>>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>>> three >>>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>>> known size. At >>>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>>> which may contain several paths. >>>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>>> two >>>>>>>>>>>> buffers are needed. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>>> >>>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>>> it makes >>>>>>>>>>>>> code much more readable. >>>>>>>>>>>> I'll fix this. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>>> >>>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>>> bytes. I >>>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>>> large enough >>>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>>> the >>>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>>> compiler. >>>>>>>>>>>> >>>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>>> spaces >>>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>>> allocated >>>>>>>>>>>> buffer. >>>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>>> >>>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>>> the same comments as above. >>>>>>>>>>>>> >>>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>>> >>>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>>> code >>>>>>>>>>>>> changed >>>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>>> respect >>>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>>> variables. >>>>>>>>>>>>> >>>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>>> -1) { >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>>> mtInternal); >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>>> os_bsd.cpp >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>>> init_system_properties_values >>>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>>> malloc to >>>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>>> allocation >>>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>>> pointers as >>>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>>> and >>>>>>>>>>>> calls to free(). >>>>>>>>>>>> >>>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>>> removes >>>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>>> local array where >>>>>>>>>>>> possible. >>>>>>>>>>>> >>>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>>> allocated in >>>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>>> Most of these >>>>>>>>>>>> frees were missing. >>>>>>>>>>>> >>>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>>> >>>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>>> fixed, >>>>>>>>>>>> too. >>>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From luchsh at linux.vnet.ibm.com Thu Apr 10 09:44:16 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Thu, 10 Apr 2014 17:44:16 +0800 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Volker, Thanks a lot for your comments, I've made another patch, http://cr.openjdk.java.net/~luchsh/JDK-8034220.v4/ On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis wrote: > Hi Jonathan, > > sorry, but I found a few more issues: > > - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise > somebody could easily crash the VM by specifying a TZ with more than > 100 characters. > Right, I've fix it by using strncpy, and also updated another usage of strcmp(). > > - you can delete the lines 871-872 because the variables are actually > not used and you can also remove the handling for "timezone == 0" > because that is actually done in getGMTOffsetID() anyway. > Nice catch, have deleted those in latest patch. > > - could you please avoid the usage of strtok. It is not intended for > usage in a multithreaded environment (see for example "man strtok" on > AIX). strtok_r is probably overkill, but you could use for example > strchr. > I've changed it to strtok_r in this patch, although strtok was only used once here, it may still impact other threads. > did you check the build on Windows? > Yes, both patches got built on Windows. > > Thank you and best regards, > Volker > > > On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu > wrote: > > Hi Volker, Masayoshi, > > > > I made another patch which fixed the problems mentioned in last mail, > > > > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ > > > > Could you pls help to take a look? > > > > Many thanks > > Jonathan > > > > > > > > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu > > wrote: > >> > >> Hi Volker, > >> > >> > >> On 2014?04?02? 23:07, Volker Simonis wrote: > >> > >> Hi Jonathan, > >> > >> thanks for updating the change. Please find my comments inline: > >> > >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu > >> wrote: > >> > >> Hi Volker, Masayoshi, > >> > >> Thanks a lot for your review, here's the updated patch, could you pls > take > >> a > >> look? > >> > >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ > >> > >> > >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis < > volker.simonis at gmail.com> > >> wrote: > >> > >> Hi Jonathan, > >> > >> thanks for doing this change. Please find some comments below: > >> > >> 1. please update the copyright year to 2014 in every file you touch > >> > >> Updated in new patch. > >> > >> 2. in CopyFiles.gmk you can simplify the change by joining the windows > >> and aix cases because on Windows OPENJDK_TARGET_OS is the same like > >> OPENJDK_TARGET_OS_API_DIR. So you can write: > >> > >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) > >> > >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib > >> > >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings > >> $(call install-file) > >> > >> COPY_FILES += $(LIBDIR)/tzmappings > >> > >> endif > >> > >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is > >> 'solaris' > >> as I observed on my AIX box, > >> solaris/lib is not the directory where tzmappings was stored for AIX. > >> So I'm keeping this change, please fix me if I was wrong about the > config. > >> > >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the > >> construction of TZMAPPINGS_SRC as shown in the code snippet above. > >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX > >> and that should be just enough here. > >> > >> > >> That's right, let me try that and also build/test on Windows platform. > >> > >> > >> 3. regarding the changes proposed by Masayoshi: I agree that we should > >> put the AIX timezone mapping code in its own function, but I don't > >> think that getPlatformTimeZoneID() would be the right place. As far as > >> I understand, getPlatformTimeZoneID() is used to get a platform time > >> zone id if the environment variable "TZ" is not set. I don't know a > >> way how this could be done on AIX (@Jonathan: maybe you know?). If > >> there would be a way to get the time zone from some system files or > >> so, then we should put this code into the AIX version of > >> getPlatformTimeZoneID(). > >> > >> I guess we may try to use /etc/envrionment file, which is basic setting > >> for > >> all processes, > >> see > >> > >> > http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm > >> The implementation of getPlatformTimeZoneID() has been updated. > >> > >> That's good! > >> > >> But the current AIX code contributed by Jonathan, actually uses the > >> time zone id from the "TZ" environment variable and just maps it to a > >> Java compatible time zone id. So I'd suggest to refactor this code > >> into a function like for example "static const char* > >> mapPlatformToJavaTimzone(const char* tz)" and call that from > >> findJavaTZ_md(). I think that would make the code easier to > >> understand. > >> > >> Agree, and have split the code into a separate static method to do the > >> mapping work. > >> > >> Good. But there's still one error in findJavaTZ_md(): > >> > >> 706 #ifdef _AIX > >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); > >> 708 #endif > >> > >> This should read: > >> > >> 706 #ifdef _AIX > >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz); > >> 708 #endif > >> > >> because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came > >> from getPlatformTimeZoneID(). > >> > >> > >> Right, but with the second approach, there may be a minor memory leak > >> here, > >> as javatz was not freed before being overwritten on AIX. will post > another > >> patch on this soon. > >> > >> > >> With the above fixed I'll push this one we get one more review from a > >> reviewer (I'm currently not an official reviewer). > >> > >> Regards, > >> Volker > >> > >> > >> @Masayoshi: what do you think, would you agree with such a solution. > >> > >> 4. I agree with Masayoshi that you should use the existing > >> getGMTOffsetID() > >> > >> Updated in new patch to eliminate duplication. > >> > >> 5. Please notice that your change breaks all Unix builds except AIX > >> because of: > >> > >> 759 } > >> 760 tzerr: > >> 761 if (javatz == NULL) { > >> 762 time_t offset; > >> ... > >> 782 } > >> 783 #endif > >> > >> I think that should read: > >> > >> 759 > >> 760 tzerr: > >> 761 if (javatz == NULL) { > >> 762 time_t offset; > >> ... > >> 782 } > >> 783 #endif > >> 784 } > >> > >> Refactoring the code in an extra function will make that error more > >> evident anyway. > >> > >> But please always build at least on one different platform (i.e. > >> Linux) to prevent such errors in the future. > >> > >> My fault, sorry for the failure, should take no chance after any manual > >> alteration. > >> > >> Regards, > >> Volker > >> > >> > >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu > >> wrote: > >> > >> Hi Jonathan, > >> > >> The AIX specific code looks OK to me. But I'd suggest the code be moved > >> to > >> getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also > >> there's a function for producing a fallback ID in "GMT?hh:mm", > >> getGMTOffsetID() which can be called in tzerr. > >> > >> Thanks, > >> Masayoshi > >> > >> > >> On 3/26/2014 3:47 PM, Jonathan Lu wrote: > >> > >> Hi ppc-aix-port-dev, core-libs-dev, > >> > >> Here's a patch for JDK-8034220, > >> > >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ > >> > >> It is trying to add the a more complete timezone mapping mechanism for > >> AIX > >> platform. > >> the changes are primarily based on IBM's commercial JDK code, which > >> includes: > >> > >> - A new timezone mapping file added under directory jdk/src/aix/lib/ > >> - Code to parse above config file, changed file is > >> src/solaris/native/java/util/TimeZone_md.c > >> - And also makefile change in make/CopyFiles.gmk to copy the config > >> file > >> > >> Could you pls help to review and give comments ? > >> > >> Cheers > >> - Jonathan > >> > >> Many thanks > >> Jonathan > >> > >> Regards > >> Jonathan > > > > > Regards Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Apr 10 10:12:43 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 10 Apr 2014 10:12:43 +0000 Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53455EEC.3030900@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <53455EEC.3030900@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAFA1E@DEWDFEMB12A.global.corp.sap> Hi, I tested the webrev, it works fine on both ppc platforms. Thanks, Goetz. -----Original Message----- From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] Sent: Mittwoch, 9. April 2014 16:54 To: Vladimir Kozlov; Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() Hi Everybody, I would like to ask the backport of the changes made for the following bug report into JDK 8 (jdk8u20): Changes applies clearly, without modifications. CR: https://bugs.openjdk.java.net/browse/JDK-8038201 Webrev: http://cr.openjdk.java.net/~dsamersoff/sponsorship/goetz/JDK-8038201/webrev.8u20/ JDK9 changeset http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/bba041a9a030 -Dmitry On 2014-04-09 01:43, Vladimir Kozlov wrote: > On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> On 2014-04-09 00:32, Vladimir Kozlov wrote: >> >>> Could you tell when you are planning to backport these changes into >>> 8u20? >> >> This week. Do I need any additional approvals? > > No need for approval but, please, send new [8u20] RFR to hotspot-dev > with links to jbs and jdk9 changeset and say that it applies cleanly (if > it is). I will review it and you can push. > It is to let people know that you backport it. > > Thanks, > Vladimir > >> >> -Dmitry >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Push done. >>>> >>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>> push it to 8u20 >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>> Thanks Dmitry and Vladimir! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Thank you, Dmitry >>>>> >>>>> We need to backport it into 8u20 too. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>> Vladimir, >>>>>> >>>>>> I can push it to RT next week. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Looks good for me! >>>>>>> >>>>>>> +1. >>>>>>> >>>>>>> Dmitry, >>>>>>> >>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>> repo? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>> call to vm_exit_... >>>>>>>>> So I removed the test and return statement. >>>>>>>>> I added the other missing FREEs. >>>>>>>>> >>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>> adapt to that scheme. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() >>>>>>>>> in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>> >>>>>>>>> os_aix.cpp: >>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>> >>>>>>>>> os_bsd.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>> >>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>> >>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>> char *v_colon = ":"; >>>>>>>>> >>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>> >>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>> >>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>> >>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>> ld_library_path); >>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>> ld_library_path */ } >>>>>>>>> ld_library_path = t; >>>>>>>>> } >>>>>>>>> >>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>> without extra copying >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>> take it into account at ll. 495 >>>>>>>>> >>>>>>>>> >>>>>>>>> os_linux.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>> >>>>>>>>> os_solaris.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please have a look at this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>> >>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>> the missing parts in here, below. >>>>>>>>>> >>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>> get along >>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>> >>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>> readability of the code. >>>>>>>>>> >>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>> the >>>>>>>>>> beginning >>>>>>>>>> and do a single allocation for them. >>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>> >>>>>>>>>> You can use >>>>>>>>>> >>>>>>>>>> MAX( >>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>> >>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>> >>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> see my comments inline. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>> >>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>> three >>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>> known size. At >>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>> which may contain several paths. >>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>> two >>>>>>>>>>> buffers are needed. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>> >>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>> it makes >>>>>>>>>>>> code much more readable. >>>>>>>>>>> I'll fix this. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>> >>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>> bytes. I >>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>> large enough >>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>> the >>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>> compiler. >>>>>>>>>>> >>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>> spaces >>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>> allocated >>>>>>>>>>> buffer. >>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>> >>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>> the same comments as above. >>>>>>>>>>>> >>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>> >>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>> code >>>>>>>>>>>> changed >>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>> respect >>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>> variables. >>>>>>>>>>>> >>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>> -1) { >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>> mtInternal); >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>> os_bsd.cpp >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>> init_system_properties_values >>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>> malloc to >>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>> allocation >>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>> pointers as >>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>> and >>>>>>>>>>> calls to free(). >>>>>>>>>>> >>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>> removes >>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>> local array where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>> allocated in >>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>> Most of these >>>>>>>>>>> frees were missing. >>>>>>>>>>> >>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>> >>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>> fixed, >>>>>>>>>>> too. >>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Thu Apr 10 10:32:20 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 10 Apr 2014 14:32:20 +0400 Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAFA1E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <53455EEC.3030900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAFA1E@DEWDFEMB12A.global.corp.sap> Message-ID: <53467334.3080601@oracle.com> Thanks! On 2014-04-10 14:12, Lindenmaier, Goetz wrote: > Hi, > > I tested the webrev, it works fine on both ppc platforms. > > Thanks, > Goetz. > > -----Original Message----- > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > Sent: Mittwoch, 9. April 2014 16:54 > To: Vladimir Kozlov; Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() > > Hi Everybody, > > I would like to ask the backport of the changes made for the following > bug report into JDK 8 (jdk8u20): > > Changes applies clearly, without modifications. > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8038201 > > Webrev: > > http://cr.openjdk.java.net/~dsamersoff/sponsorship/goetz/JDK-8038201/webrev.8u20/ > > JDK9 changeset > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/bba041a9a030 > > -Dmitry > > On 2014-04-09 01:43, Vladimir Kozlov wrote: >> On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >>> Vladimir, >>> >>> On 2014-04-09 00:32, Vladimir Kozlov wrote: >>> >>>> Could you tell when you are planning to backport these changes into >>>> 8u20? >>> >>> This week. Do I need any additional approvals? >> >> No need for approval but, please, send new [8u20] RFR to hotspot-dev >> with links to jbs and jdk9 changeset and say that it applies cleanly (if >> it is). I will review it and you can push. >> It is to let people know that you backport it. >> >> Thanks, >> Vladimir >> >>> >>> -Dmitry >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>>> Goetz, >>>>> >>>>> Push done. >>>>> >>>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>>> push it to 8u20 >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>>> Thanks Dmitry and Vladimir! >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>> in init_system_properties_values() >>>>>> >>>>>> Thank you, Dmitry >>>>>> >>>>>> We need to backport it into 8u20 too. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>>> Vladimir, >>>>>>> >>>>>>> I can push it to RT next week. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Looks good for me! >>>>>>>> >>>>>>>> +1. >>>>>>>> >>>>>>>> Dmitry, >>>>>>>> >>>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>>> repo? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>>> call to vm_exit_... >>>>>>>>>> So I removed the test and return statement. >>>>>>>>>> I added the other missing FREEs. >>>>>>>>>> >>>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>>> adapt to that scheme. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>> malloc() >>>>>>>>>> in init_system_properties_values() >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>>> >>>>>>>>>> os_aix.cpp: >>>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>>> >>>>>>>>>> os_bsd.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>>> >>>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>>> >>>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>>> char *v_colon = ":"; >>>>>>>>>> >>>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>>> >>>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>>> >>>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>>> >>>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>>> ld_library_path); >>>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>>> ld_library_path */ } >>>>>>>>>> ld_library_path = t; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>>> without extra copying >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>>> take it into account at ll. 495 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> os_linux.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please have a look at this new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>>> the missing parts in here, below. >>>>>>>>>>> >>>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>>> get along >>>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>>> >>>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>>> readability of the code. >>>>>>>>>>> >>>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>>> the >>>>>>>>>>> beginning >>>>>>>>>>> and do a single allocation for them. >>>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Goetz, >>>>>>>>>>> >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>>> >>>>>>>>>>> You can use >>>>>>>>>>> >>>>>>>>>>> MAX( >>>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>>> >>>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>>> >>>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> see my comments inline. >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>>> >>>>>>>>>>>>> Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>>> >>>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>>> three >>>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>>> known size. At >>>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>>> which may contain several paths. >>>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>>> two >>>>>>>>>>>> buffers are needed. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>>> >>>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>>> it makes >>>>>>>>>>>>> code much more readable. >>>>>>>>>>>> I'll fix this. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>>> >>>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>>> bytes. I >>>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>>> large enough >>>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>>> the >>>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>>> compiler. >>>>>>>>>>>> >>>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>>> spaces >>>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>>> allocated >>>>>>>>>>>> buffer. >>>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>>> >>>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>>> the same comments as above. >>>>>>>>>>>>> >>>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>>> >>>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>>> code >>>>>>>>>>>>> changed >>>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>>> respect >>>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>>> variables. >>>>>>>>>>>>> >>>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>>> -1) { >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>>> mtInternal); >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>>> os_bsd.cpp >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>>> init_system_properties_values >>>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>>> malloc to >>>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>>> allocation >>>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>>> pointers as >>>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>>> and >>>>>>>>>>>> calls to free(). >>>>>>>>>>>> >>>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>>> removes >>>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>>> local array where >>>>>>>>>>>> possible. >>>>>>>>>>>> >>>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>>> allocated in >>>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>>> Most of these >>>>>>>>>>>> frees were missing. >>>>>>>>>>>> >>>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>>> >>>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>>> fixed, >>>>>>>>>>>> too. >>>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Thu Apr 10 13:00:33 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 10 Apr 2014 17:00:33 +0400 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <53446D8A.5020207@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> Message-ID: <534695F1.6060100@oracle.com> Goetz, Vladimir, done. http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/6048424d3865 -Dmitry On 2014-04-09 01:43, Vladimir Kozlov wrote: > On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> On 2014-04-09 00:32, Vladimir Kozlov wrote: >> >>> Could you tell when you are planning to backport these changes into >>> 8u20? >> >> This week. Do I need any additional approvals? > > No need for approval but, please, send new [8u20] RFR to hotspot-dev > with links to jbs and jdk9 changeset and say that it applies cleanly (if > it is). I will review it and you can push. > It is to let people know that you backport it. > > Thanks, > Vladimir > >> >> -Dmitry >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Push done. >>>> >>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>> push it to 8u20 >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>> Thanks Dmitry and Vladimir! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Thank you, Dmitry >>>>> >>>>> We need to backport it into 8u20 too. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>> Vladimir, >>>>>> >>>>>> I can push it to RT next week. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Looks good for me! >>>>>>> >>>>>>> +1. >>>>>>> >>>>>>> Dmitry, >>>>>>> >>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>> repo? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>> call to vm_exit_... >>>>>>>>> So I removed the test and return statement. >>>>>>>>> I added the other missing FREEs. >>>>>>>>> >>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>> adapt to that scheme. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() >>>>>>>>> in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>> >>>>>>>>> os_aix.cpp: >>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>> >>>>>>>>> os_bsd.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>> >>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>> >>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>> char *v_colon = ":"; >>>>>>>>> >>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>> >>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>> >>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>> >>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>> ld_library_path); >>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>> ld_library_path */ } >>>>>>>>> ld_library_path = t; >>>>>>>>> } >>>>>>>>> >>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>> without extra copying >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>> take it into account at ll. 495 >>>>>>>>> >>>>>>>>> >>>>>>>>> os_linux.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>> >>>>>>>>> os_solaris.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please have a look at this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>> >>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>> the missing parts in here, below. >>>>>>>>>> >>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>> get along >>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>> >>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>> readability of the code. >>>>>>>>>> >>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>> the >>>>>>>>>> beginning >>>>>>>>>> and do a single allocation for them. >>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>> >>>>>>>>>> You can use >>>>>>>>>> >>>>>>>>>> MAX( >>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>> >>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>> >>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> see my comments inline. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>> >>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>> three >>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>> known size. At >>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>> which may contain several paths. >>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>> two >>>>>>>>>>> buffers are needed. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>> >>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>> it makes >>>>>>>>>>>> code much more readable. >>>>>>>>>>> I'll fix this. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>> >>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>> bytes. I >>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>> large enough >>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>> the >>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>> compiler. >>>>>>>>>>> >>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>> spaces >>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>> allocated >>>>>>>>>>> buffer. >>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>> >>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>> the same comments as above. >>>>>>>>>>>> >>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>> >>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>> code >>>>>>>>>>>> changed >>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>> respect >>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>> variables. >>>>>>>>>>>> >>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>> -1) { >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>> mtInternal); >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>> os_bsd.cpp >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>> init_system_properties_values >>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>> malloc to >>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>> allocation >>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>> pointers as >>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>> and >>>>>>>>>>> calls to free(). >>>>>>>>>>> >>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>> removes >>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>> local array where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>> allocated in >>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>> Most of these >>>>>>>>>>> frees were missing. >>>>>>>>>>> >>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>> >>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>> fixed, >>>>>>>>>>> too. >>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From goetz.lindenmaier at sap.com Thu Apr 10 14:08:11 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 10 Apr 2014 14:08:11 +0000 Subject: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <534695F1.6060100@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <534695F1.6060100@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAFB4F@DEWDFEMB12A.global.corp.sap> Thanks for the help! Works fine. Best regards, Goetz -----Original Message----- From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] Sent: Donnerstag, 10. April 2014 15:01 To: Vladimir Kozlov; Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() Goetz, Vladimir, done. http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/6048424d3865 -Dmitry On 2014-04-09 01:43, Vladimir Kozlov wrote: > On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >> Vladimir, >> >> On 2014-04-09 00:32, Vladimir Kozlov wrote: >> >>> Could you tell when you are planning to backport these changes into >>> 8u20? >> >> This week. Do I need any additional approvals? > > No need for approval but, please, send new [8u20] RFR to hotspot-dev > with links to jbs and jdk9 changeset and say that it applies cleanly (if > it is). I will review it and you can push. > It is to let people know that you backport it. > > Thanks, > Vladimir > >> >> -Dmitry >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>> Goetz, >>>> >>>> Push done. >>>> >>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>> push it to 8u20 >>>> >>>> -Dmitry >>>> >>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>> Thanks Dmitry and Vladimir! >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>> in init_system_properties_values() >>>>> >>>>> Thank you, Dmitry >>>>> >>>>> We need to backport it into 8u20 too. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>> Vladimir, >>>>>> >>>>>> I can push it to RT next week. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Looks good for me! >>>>>>> >>>>>>> +1. >>>>>>> >>>>>>> Dmitry, >>>>>>> >>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>> repo? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>> call to vm_exit_... >>>>>>>>> So I removed the test and return statement. >>>>>>>>> I added the other missing FREEs. >>>>>>>>> >>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>> adapt to that scheme. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>> malloc() >>>>>>>>> in init_system_properties_values() >>>>>>>>> >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>> >>>>>>>>> os_aix.cpp: >>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>> >>>>>>>>> os_bsd.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>> >>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>> >>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>> char *v_colon = ":"; >>>>>>>>> >>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>> >>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>> >>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>> >>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>> ld_library_path); >>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>> ld_library_path */ } >>>>>>>>> ld_library_path = t; >>>>>>>>> } >>>>>>>>> >>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>> without extra copying >>>>>>>>> >>>>>>>>> >>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>> take it into account at ll. 495 >>>>>>>>> >>>>>>>>> >>>>>>>>> os_linux.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>> >>>>>>>>> os_solaris.cpp: >>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please have a look at this new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>> >>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>> the missing parts in here, below. >>>>>>>>>> >>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>> get along >>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>> >>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>> readability of the code. >>>>>>>>>> >>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>> the >>>>>>>>>> beginning >>>>>>>>>> and do a single allocation for them. >>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>> >>>>>>>>>> You can use >>>>>>>>>> >>>>>>>>>> MAX( >>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>> >>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>> >>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> see my comments inline. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>> >>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>> three >>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>> known size. At >>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>> which may contain several paths. >>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>> two >>>>>>>>>>> buffers are needed. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>> >>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>> it makes >>>>>>>>>>>> code much more readable. >>>>>>>>>>> I'll fix this. >>>>>>>>>>> >>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>> >>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>> bytes. I >>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>> large enough >>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>> the >>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>> compiler. >>>>>>>>>>> >>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>> spaces >>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>> allocated >>>>>>>>>>> buffer. >>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>> >>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>> the same comments as above. >>>>>>>>>>>> >>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>> >>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>> code >>>>>>>>>>>> changed >>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>> respect >>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>> variables. >>>>>>>>>>>> >>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>> -1) { >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>> mtInternal); >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>> os_bsd.cpp >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>> init_system_properties_values >>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>> malloc to >>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>> allocation >>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>> pointers as >>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>> and >>>>>>>>>>> calls to free(). >>>>>>>>>>> >>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>> removes >>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>> local array where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>> allocated in >>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>> Most of these >>>>>>>>>>> frees were missing. >>>>>>>>>>> >>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>> >>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>> fixed, >>>>>>>>>>> too. >>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From vladimir.kozlov at oracle.com Thu Apr 10 16:18:52 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Apr 2014 09:18:52 -0700 Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAFA1E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEAA150@DEWDFEMB12A.global.corp.sap> <5331566A.9050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAA8E8@DEWDFEMB12A.global.corp.sap> <5333F417.2010902@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAAA08@DEWDFEMB12A.global.corp.sap> <53347390.2000208@oracle.com> <5334757E.9080104@oracle.com> <533478FF.6030303@oracle.com> <5334795D.1070604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAB48B@DEWDFEMB12A.global.corp.sap> <533AB62D.1010501@oracle.com> <53445CF2.50909@oracle.com> <534467CB.8010307@oracle.com> <53446D8A.5020207@oracle.com> <53455EEC.3030900@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEAFA1E@DEWDFEMB12A.global.corp.sap> Message-ID: <5346C46C.2030407@oracle.com> Thank you, Goetz Vladimir On 4/10/14 3:12 AM, Lindenmaier, Goetz wrote: > Hi, > > I tested the webrev, it works fine on both ppc platforms. > > Thanks, > Goetz. > > -----Original Message----- > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > Sent: Mittwoch, 9. April 2014 16:54 > To: Vladimir Kozlov; Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: [8u20] RFR(M): 8038201: Clean up misleading usage of malloc() in init_system_properties_values() > > Hi Everybody, > > I would like to ask the backport of the changes made for the following > bug report into JDK 8 (jdk8u20): > > Changes applies clearly, without modifications. > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8038201 > > Webrev: > > http://cr.openjdk.java.net/~dsamersoff/sponsorship/goetz/JDK-8038201/webrev.8u20/ > > JDK9 changeset > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/bba041a9a030 > > -Dmitry > > On 2014-04-09 01:43, Vladimir Kozlov wrote: >> On 4/8/14 2:19 PM, Dmitry Samersoff wrote: >>> Vladimir, >>> >>> On 2014-04-09 00:32, Vladimir Kozlov wrote: >>> >>>> Could you tell when you are planning to backport these changes into >>>> 8u20? >>> >>> This week. Do I need any additional approvals? >> >> No need for approval but, please, send new [8u20] RFR to hotspot-dev >> with links to jbs and jdk9 changeset and say that it applies cleanly (if >> it is). I will review it and you can push. >> It is to let people know that you backport it. >> >> Thanks, >> Vladimir >> >>> >>> -Dmitry >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/1/14 5:50 AM, Dmitry Samersoff wrote: >>>>> Goetz, >>>>> >>>>> Push done. >>>>> >>>>> Let it bakes for some times in JDK9 (at least two nightlies) than I'll >>>>> push it to 8u20 >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-03-27 23:52, Lindenmaier, Goetz wrote: >>>>>> Thanks Dmitry and Vladimir! >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Thursday, March 27, 2014 8:18 PM >>>>>> To: Dmitry Samersoff; Lindenmaier, Goetz; >>>>>> hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of malloc() >>>>>> in init_system_properties_values() >>>>>> >>>>>> Thank you, Dmitry >>>>>> >>>>>> We need to backport it into 8u20 too. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>> On 3/27/14 12:16 PM, Dmitry Samersoff wrote: >>>>>>> Vladimir, >>>>>>> >>>>>>> I can push it to RT next week. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-27 23:01, Vladimir Kozlov wrote: >>>>>>>> On 3/27/14 11:53 AM, Dmitry Samersoff wrote: >>>>>>>>> Goetz, >>>>>>>>> >>>>>>>>> Looks good for me! >>>>>>>> >>>>>>>> +1. >>>>>>>> >>>>>>>> Dmitry, >>>>>>>> >>>>>>>> Do you want me to push it into Comp repo or you will do it into RT >>>>>>>> repo? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-03-27 18:56, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> thanks for the thorough review and catching the forgotten FREEs! >>>>>>>>>> I had a look at set_boot_path(). That will never return false, >>>>>>>>>> as it also calls NEW_C_HEAP_ARRAY that will abort the VM. >>>>>>>>>> In addition it would be wrong to return, there should be a >>>>>>>>>> call to vm_exit_... >>>>>>>>>> So I removed the test and return statement. >>>>>>>>>> I added the other missing FREEs. >>>>>>>>>> >>>>>>>>>> I also implemented your proposal with only one sprintf >>>>>>>>>> for the ld_library_path, and did so for bsd, aix and linux >>>>>>>>>> to get it more similar. Solaris seems too different to >>>>>>>>>> adapt to that scheme. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.03/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>> Sent: Donnerstag, 27. M?rz 2014 10:49 >>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>> malloc() >>>>>>>>>> in init_system_properties_values() >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>> Thank you for doing it - code is much cleaner now. >>>>>>>>>> >>>>>>>>>> os_aix.cpp: >>>>>>>>>> Did you forget FREE_C_HEAP_ARRAY() at ll.548 and ll.576? >>>>>>>>>> >>>>>>>>>> os_bsd.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 389, ll. 477 >>>>>>>>>> >>>>>>>>>> ll.407 sprintf could be moved to ll.420 under else >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.497 (and below) a trick like one below: >>>>>>>>>> >>>>>>>>>> char *l = ::getenv("JAVA_LIBRARY_PATH"); >>>>>>>>>> char *v = ::getenv("DYLD_LIBRARY_PATH"); >>>>>>>>>> char *v_colon = ":"; >>>>>>>>>> >>>>>>>>>> if (l != NULL || v != NULL) { >>>>>>>>>> >>>>>>>>>> if (v == NULL){ v = "", v_colon = ""; }; >>>>>>>>>> if (l == NULL){ l = "", v_colon = ""; }; >>>>>>>>>> >>>>>>>>>> t = (char *) ... /* allocate memory for all strings */ >>>>>>>>>> >>>>>>>>>> sprintf(t, "%s%s%s:%s", v,v_colon, l, >>>>>>>>>> ld_library_path); >>>>>>>>>> if (ld_library_path != buf){ ... /* free >>>>>>>>>> ld_library_path */ } >>>>>>>>>> ld_library_path = t; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> might be useful to assemble the path in one shot, >>>>>>>>>> without extra copying >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ll.520 As you appending constant value ":.", you can just >>>>>>>>>> take it into account at ll. 495 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> os_linux.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 400 >>>>>>>>>> >>>>>>>>>> os_solaris.cpp: >>>>>>>>>> missed FREE_C_HEAP_ARRAY() at ll. 714 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-03-27 12:54, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please have a look at this new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> Dmitry, sorry I forgot to reply to all in my last mail. I copied >>>>>>>>>>> the missing parts in here, below. >>>>>>>>>>> >>>>>>>>>>> Avoiding big stack allocations I wanted to remove the >>>>>>>>>>> buf[MAXPATHLEN] >>>>>>>>>>> at the beginning of the function, too. That's why I said I can't >>>>>>>>>>> get along >>>>>>>>>>> with a single allocation. strlen(v) is only known later. >>>>>>>>>>> >>>>>>>>>>> I could redesign the whole code, computing sizes first, and then >>>>>>>>>>> doing a single allocation, but I think that doesn't help the >>>>>>>>>>> readability of the code. >>>>>>>>>>> >>>>>>>>>>> So now I compute the max size of all buffers I can estimate at >>>>>>>>>>> the >>>>>>>>>>> beginning >>>>>>>>>>> and do a single allocation for them. >>>>>>>>>>> Also, bsd contains an extra section for __APPLE__. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Goetz, >>>>>>>>>>> >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, which may contain several paths. >>>>>>>>>>> >>>>>>>>>>> You can use >>>>>>>>>>> >>>>>>>>>>> MAX( >>>>>>>>>>> strlen(v) + 1 + sizeof(DEFAULT_LIBPATH) + 1, >>>>>>>>>>> MAXPATHLEN + sizeof(EXTENSIONS_DIR) + >>>>>>>>>>> sizeof(ENDORSED_DIR) >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> as the size for a buffer at ll. 556 and have one allocation. >>>>>>>>>>> >>>>>>>>>>> But I'm fine with two different allocations. >>>>>>>>>>> >>>>>>>>>>> Thank you for addressing other concerns. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 17:55, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> see my comments inline. >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>>> Sent: Dienstag, 25. M?rz 2014 11:12 >>>>>>>>>>>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >>>>>>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR(M): 8038201: Clean up misleading usage of >>>>>>>>>>>>> malloc() in init_system_properties_values() >>>>>>>>>>>>> >>>>>>>>>>>>> Goetz, >>>>>>>>>>>>> >>>>>>>>>>>>> os_aix.cpp: 565 >>>>>>>>>>>>> >>>>>>>>>>>>> It might be better to allocate one buffer that satisfy all >>>>>>>>>>>>> three >>>>>>>>>>>>> sprintf() calls at ll. 556 and free it at ll. 574 >>>>>>>>>>>> I need at least two allocations. The first one has a statically >>>>>>>>>>>> known size. At >>>>>>>>>>>> least more or less, as I know there will be only one path of >>>>>>>>>>>> unknown size in the buffer. >>>>>>>>>>>> The allocation in 556 must know about the length of the >>>>>>>>>>>> getenv("LIBPATH") result, >>>>>>>>>>>> which may contain several paths. >>>>>>>>>>>> Also, in the other files, paths are concatenated, so at least >>>>>>>>>>>> two >>>>>>>>>>>> buffers are needed. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 350 >>>>>>>>>>>>> >>>>>>>>>>>>> I would prefer to have the single #ifdef __APPLE__ block, >>>>>>>>>>>>> it makes >>>>>>>>>>>>> code much more readable. >>>>>>>>>>>> I'll fix this. >>>>>>>>>>>> >>>>>>>>>>>>> os_bsd.cpp: 485 >>>>>>>>>>>>> >>>>>>>>>>>>> you replace malloc to on-stack allocation of more than 4096 >>>>>>>>>>>>> bytes. I >>>>>>>>>>>>> think this allocation should be done through NEW_C_HEAP_ARRAY. >>>>>>>>>>>> > see also comments to os_aix above - you can allocate >>>>>>>>>>>> large enough >>>>>>>>>>>>> buffer once and than reuse it. >>>>>>>>>>>> Is there a boundary at 4k? There was a char buf[MAXPATHLEN] in >>>>>>>>>>>> the >>>>>>>>>>>> code anyways, so I thought a few bytes more would not matter. >>>>>>>>>>>> The space required by the existing buf can be reused by the C >>>>>>>>>>>> compiler. >>>>>>>>>>>> >>>>>>>>>>>> But I'll fix that and only use allocated memory. >>>>>>>>>>>> I'll remove the buf that was already there and replace all >>>>>>>>>>>> spaces >>>>>>>>>>>> I can estimate by MAXPATHLEN + some offset by a single, >>>>>>>>>>>> allocated >>>>>>>>>>>> buffer. >>>>>>>>>>>> I'll do this the same on all four platforms. >>>>>>>>>>>> >>>>>>>>>>>>> os_linux.cpp: 434 >>>>>>>>>>>>> the same comments as above. >>>>>>>>>>>>> >>>>>>>>>>>>> os_solaris.cpp: 728 >>>>>>>>>>>>> >>>>>>>>>>>>> As soon as you doing cleanup, I would love to have this >>>>>>>>>>>>> code >>>>>>>>>>>>> changed >>>>>>>>>>>>> a bit. It comes from solaris man page long time ago and doesn't >>>>>>>>>>>>> respect >>>>>>>>>>>>> hotspot convention of using underscore to indicate class global >>>>>>>>>>>>> variables. >>>>>>>>>>>>> >>>>>>>>>>>>> Could you change it to something like: >>>>>>>>>>>>> Dl_serinfo info_sz, *info; >>>>>>>>>>>> Yes, I'll fix that. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> if (dlinfo(RTLD_SELF, RTLD_DI_SERINFOSIZE, (void *)&info_sz) == >>>>>>>>>>> -1) { >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> info = (Dl_serinfo*)NEW_C_HEAP_ARRAY(char, info_sz.dls_size, >>>>>>>>>>> mtInternal); >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> os_solaris.cpp: 829 >>>>>>>>>>> The same comment about on-stack allocation as for >>>>>>>>>>> os_bsd.cpp >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-03-25 01:50, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please review and test this change. I please need a sponsor. >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8038201-sec/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> This change addresses the implementation of >>>>>>>>>>>> init_system_properties_values >>>>>>>>>>>> on aix, linux, solaris and bsd. >>>>>>>>>>>> In init_system_properties_values a macro was defined mapping >>>>>>>>>>>> malloc to >>>>>>>>>>>> NEW_C_HEAP_ARRAY. NEW_C_HEAP_ARRAY checks for successful >>>>>>>>>>>> allocation >>>>>>>>>>>> or exits the VM. The code of this method handles the allocated >>>>>>>>>>>> pointers as >>>>>>>>>>>> allocated with real malloc, i.e., there were checks for NULL >>>>>>>>>>>> and >>>>>>>>>>>> calls to free(). >>>>>>>>>>>> >>>>>>>>>>>> This change replaces the macro malloc with NEW_C_HEAP_ARRAY and >>>>>>>>>>>> removes >>>>>>>>>>>> the unnecessary checks making the code clearer. Also, it uses a >>>>>>>>>>>> local array where >>>>>>>>>>>> possible. >>>>>>>>>>>> >>>>>>>>>>>> The allocated memory is passed to calls that end up at >>>>>>>>>>>> SystemProperty::set_value(). >>>>>>>>>>>> set_value copies the strings passed. Thus the memory >>>>>>>>>>>> allocated in >>>>>>>>>>>> init_system_properties_values must be freed after these calls. >>>>>>>>>>>> Most of these >>>>>>>>>>>> frees were missing. >>>>>>>>>>>> >>>>>>>>>>>> This change adds the missing frees. >>>>>>>>>>>> >>>>>>>>>>>> Testing this change I ran into a warning in ppc code which I >>>>>>>>>>>> fixed, >>>>>>>>>>>> too. >>>>>>>>>>>> I did some local test. I'll get broader tests by Wednesday. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From vladimir.kozlov at oracle.com Fri Apr 11 01:55:57 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 11 Apr 2014 01:55:57 +0000 Subject: hg: ppc-aix-port/stage: 5 new changesets Message-ID: <201404110155.s3B1twOo028096@aojmv0008> Changeset: d904a8b799d4 Author: kvn Date: 2014-04-03 09:34 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/rev/d904a8b799d4 8036767: PPC64: Support for little endian execution model Reviewed-by: ihse, erikj, simonis Contributed-by: asmundak at google.com ! common/autoconf/build-aux/config.guess ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 Changeset: ab3b7065648f Author: katleman Date: 2014-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/rev/ab3b7065648f Added tag jdk8u20-b07 for changeset 6403ef94cb0d ! .hgtags Changeset: b7750b6ee157 Author: amurillo Date: 2014-04-01 11:07 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/rev/b7750b6ee157 Merge Changeset: 00b798f15cc6 Author: katleman Date: 2014-04-02 09:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/rev/00b798f15cc6 Added tag jdk8u20-b08 for changeset b7750b6ee157 ! .hgtags Changeset: d832d813d65b Author: amurillo Date: 2014-04-04 09:54 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/rev/d832d813d65b Merge From vladimir.kozlov at oracle.com Fri Apr 11 01:56:00 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 11 Apr 2014 01:56:00 +0000 Subject: hg: ppc-aix-port/stage/corba: 2 new changesets Message-ID: <201404110156.s3B1u1DO028149@aojmv0008> Changeset: 4e4a75376185 Author: katleman Date: 2014-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/corba/rev/4e4a75376185 Added tag jdk8u20-b07 for changeset 32b9c4f0ab3c ! .hgtags Changeset: 0344396d09b0 Author: katleman Date: 2014-04-02 09:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/corba/rev/0344396d09b0 Added tag jdk8u20-b08 for changeset 4e4a75376185 ! .hgtags From vladimir.kozlov at oracle.com Fri Apr 11 01:56:03 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 11 Apr 2014 01:56:03 +0000 Subject: hg: ppc-aix-port/stage/jaxp: 2 new changesets Message-ID: <201404110156.s3B1u5jG028202@aojmv0008> Changeset: 68e2ea32f927 Author: katleman Date: 2014-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxp/rev/68e2ea32f927 Added tag jdk8u20-b07 for changeset 30b8baceb72b ! .hgtags Changeset: ed0d61eed678 Author: katleman Date: 2014-04-02 09:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxp/rev/ed0d61eed678 Added tag jdk8u20-b08 for changeset 68e2ea32f927 ! .hgtags From vladimir.kozlov at oracle.com Fri Apr 11 01:56:12 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 11 Apr 2014 01:56:12 +0000 Subject: hg: ppc-aix-port/stage/jaxws: 2 new changesets Message-ID: <201404110156.s3B1uEiN028284@aojmv0008> Changeset: bc6d2f3426f3 Author: katleman Date: 2014-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxws/rev/bc6d2f3426f3 Added tag jdk8u20-b07 for changeset a61ba2e3e6c8 ! .hgtags Changeset: 2e76ce4ec993 Author: katleman Date: 2014-04-02 09:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jaxws/rev/2e76ce4ec993 Added tag jdk8u20-b08 for changeset bc6d2f3426f3 ! .hgtags From vladimir.kozlov at oracle.com Fri Apr 11 01:56:19 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 11 Apr 2014 01:56:19 +0000 Subject: hg: ppc-aix-port/stage/langtools: 2 new changesets Message-ID: <201404110156.s3B1uM5x028370@aojmv0008> Changeset: 0f821eb7e92b Author: katleman Date: 2014-03-26 12:01 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/0f821eb7e92b Added tag jdk8u20-b07 for changeset 1a57c569cb81 ! .hgtags Changeset: dbe60d62f421 Author: katleman Date: 2014-04-02 09:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/langtools/rev/dbe60d62f421 Added tag jdk8u20-b08 for changeset 0f821eb7e92b ! .hgtags From vladimir.kozlov at oracle.com Fri Apr 11 01:56:25 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 11 Apr 2014 01:56:25 +0000 Subject: hg: ppc-aix-port/stage/nashorn: 2 new changesets Message-ID: <201404110156.s3B1uQjo028421@aojmv0008> Changeset: 2282c86cb1a9 Author: katleman Date: 2014-03-26 12:01 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/nashorn/rev/2282c86cb1a9 Added tag jdk8u20-b07 for changeset 7e89db817ed0 ! .hgtags Changeset: e6ed9573c644 Author: katleman Date: 2014-04-02 09:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/nashorn/rev/e6ed9573c644 Added tag jdk8u20-b08 for changeset 2282c86cb1a9 ! .hgtags From vladimir.kozlov at oracle.com Fri Apr 11 02:05:36 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 11 Apr 2014 02:05:36 +0000 Subject: hg: ppc-aix-port/stage/jdk: 3 new changesets Message-ID: <201404110205.s3B25rsS000041@aojmv0008> Changeset: 0f2d82ba2b40 Author: katleman Date: 2014-03-26 12:01 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/0f2d82ba2b40 Added tag jdk8u20-b07 for changeset db30cb9eb18d ! .hgtags Changeset: 0e717bd55bc9 Author: amurillo Date: 2014-04-01 11:07 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/0e717bd55bc9 Merge Changeset: 797c01fadad7 Author: katleman Date: 2014-04-02 09:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/rev/797c01fadad7 Added tag jdk8u20-b08 for changeset 0e717bd55bc9 ! .hgtags From vladimir.kozlov at oracle.com Fri Apr 11 02:50:08 2014 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 11 Apr 2014 02:50:08 +0000 Subject: hg: ppc-aix-port/stage/hotspot: 39 new changesets Message-ID: <201404110250.s3B2oifp006445@aojmv0008> Changeset: 3829d0343db0 Author: iignatyev Date: 2014-03-27 17:29 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/3829d0343db0 8038193: Add command line option tests for BMI options Reviewed-by: iveresov, kvn, iignatyev Contributed-by: filipp.zhinkin at oracle.com + test/compiler/arguments/BMICommandLineOptionTestBase.java + test/compiler/arguments/BMISupportedCPUTest.java + test/compiler/arguments/BMIUnsupportedCPUTest.java + test/compiler/arguments/TestUseBMI1InstructionsOnSupportedCPU.java + test/compiler/arguments/TestUseBMI1InstructionsOnUnsupportedCPU.java + test/compiler/arguments/TestUseCountLeadingZerosInstructionOnSupportedCPU.java + test/compiler/arguments/TestUseCountLeadingZerosInstructionOnUnsupportedCPU.java + test/compiler/arguments/TestUseCountTrailingZerosInstructionOnSupportedCPU.java + test/compiler/arguments/TestUseCountTrailingZerosInstructionOnUnsupportedCPU.java + test/testlibrary/com/oracle/java/testlibrary/ExitCode.java ! test/testlibrary/com/oracle/java/testlibrary/Utils.java + test/testlibrary/com/oracle/java/testlibrary/cli/CPUSpecificCommandLineOptionTest.java + test/testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java Changeset: 4abb719c5620 Author: iignatyev Date: 2014-03-27 11:17 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/4abb719c5620 8038240: new WB API to get nmethod Reviewed-by: morris, kvn ! src/share/vm/prims/whitebox.cpp ! src/share/vm/prims/whitebox.hpp ! test/compiler/whitebox/CompilerWhiteBoxTest.java + test/compiler/whitebox/GetNMethodTest.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java + test/testlibrary/whitebox/sun/hotspot/code/NMethod.java Changeset: 75ad4240c15c Author: vlivanov Date: 2014-03-28 10:04 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/75ad4240c15c 8036667: "assert(adr->is_AddP() && adr->in(AddPNode::Offset)->is_Con()) failed: offset is a constant" with FoldStableValues on Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp Changeset: f47fa50d9b9c Author: vlivanov Date: 2014-03-28 10:12 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/f47fa50d9b9c 8035887: VM crashes trying to force inlining the recursive call Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/runtime/globals.hpp Changeset: 248ff38d2950 Author: vlivanov Date: 2014-03-28 10:13 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/248ff38d2950 8035828: Turn on @Stable support in VM Reviewed-by: jrose, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/globals.hpp + test/compiler/stable/TestStableBoolean.java + test/compiler/stable/TestStableByte.java + test/compiler/stable/TestStableChar.java + test/compiler/stable/TestStableDouble.java + test/compiler/stable/TestStableFloat.java + test/compiler/stable/TestStableInt.java + test/compiler/stable/TestStableLong.java + test/compiler/stable/TestStableObject.java + test/compiler/stable/TestStableShort.java Changeset: 758ee76af3cd Author: vlivanov Date: 2014-03-28 12:22 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/758ee76af3cd Merge Changeset: 556a5a987c41 Author: amurillo Date: 2014-03-18 10:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/556a5a987c41 Merge ! .hgtags Changeset: 9d5e92af8f09 Author: lana Date: 2014-03-18 12:40 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/9d5e92af8f09 Merge ! .hgtags ! make/hotspot_version Changeset: 7ce7247df891 Author: lana Date: 2014-03-24 13:14 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/7ce7247df891 Merge ! .hgtags Changeset: f0ea4d3df129 Author: amurillo Date: 2014-03-25 10:48 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/f0ea4d3df129 Merge ! .hgtags ! make/hotspot_version - src/share/vm/gc_implementation/g1/heapRegionSets.cpp - src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: 2627c7be4279 Author: amurillo Date: 2014-03-28 15:22 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/2627c7be4279 Merge ! .hgtags ! make/hotspot_version Changeset: a07f90a9eaad Author: amurillo Date: 2014-03-28 15:22 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/a07f90a9eaad Added tag hs25.20-b08 for changeset 2627c7be4279 ! .hgtags Changeset: d5818eeedb40 Author: amurillo Date: 2014-03-28 15:29 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/d5818eeedb40 8038639: new hotspot build - hs25.20-b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f42c10a3d4b1 Author: minqi Date: 2014-03-31 13:09 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/f42c10a3d4b1 7090324: gclog rotation via external tool Summary: GC log rotation can be set via java command line, but customer sometime need to sync with OS level rotation setting. Reviewed-by: sla, minqi, ehelin Contributed-by: suenaga.yasumasa at lab.ntt.co.jp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/gc/TestGCLogRotationViaJcmd.java Changeset: 8a84bedf7173 Author: dholmes Date: 2014-03-31 23:49 -0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/8a84bedf7173 8016039: jvm.lib is missing from export list unless building server Summary: make the export declaration unconditional Reviewed-by: sla, sspitsyn ! make/windows/makefiles/defs.make Changeset: 0118c8c7b80f Author: kvn Date: 2014-03-31 13:08 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/0118c8c7b80f 8038633: crash in VM_Version::get_processor_features() on startup Summary: Windows need an exception wrapper around getPsrInfo_stub() call in order to properly handle SEGV for YMM registers test. Reviewed-by: iveresov, iignatyev ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/vm/prims/jni.cpp Changeset: 56e7f5560e60 Author: kvn Date: 2014-04-02 11:24 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/56e7f5560e60 8036767: PPC64: Support for little endian execution model Reviewed-by: goetz, kvn, dholmes, simonis Contributed-by: asmundak at google.com ! make/linux/Makefile ! make/linux/makefiles/defs.make ! make/linux/makefiles/ppc64.make ! src/cpu/ppc/vm/assembler_ppc.hpp ! src/cpu/ppc/vm/bytes_ppc.hpp ! src/os/linux/vm/os_linux.cpp + src/os_cpu/linux_ppc/vm/bytes_linux_ppc.inline.hpp Changeset: 876390ee9b6f Author: iveresov Date: 2014-04-02 11:24 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/876390ee9b6f 8039043: Implicit null check is in the wrong place in C1 -UseCompressedOops Summary: Null check is placed in a wrong place when storing a null to an object field on x64 with compressed oops off Reviewed-by: roland, vlivanov, kvn ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp + test/compiler/codegen/C1NullCheckOfNullStore.java Changeset: 6df24530bf14 Author: iveresov Date: 2014-04-03 16:37 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/6df24530bf14 Merge Changeset: bfdf528be8e8 Author: tschatzl Date: 2014-04-04 10:43 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/bfdf528be8e8 8038498: Fix includes and C inlining after 8035330 Summary: Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure broke the debug build on AIX. The method do_oop_partial_array() is added in a header, but requires the inline function par_write_ref() through several inlined calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined as the corresponding inline header and is not included. The AIX debug VM does not start because of the missing symbol. This change solves this by cleaning up include dependencies. Reviewed-by: tschatzl, stefank ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: b257acb35d3e Author: zgu Date: 2013-12-16 10:57 -0800 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/b257acb35d3e 8026300: VM warning: increase O_BUFLEN in ostream.hpp -- output truncated occurs with fastdebug VM when printing flags Summary: Fixed wrong print string format Reviewed-by: sla, ccheung ! src/share/vm/runtime/globals.cpp Changeset: b158a8444810 Author: katleman Date: 2014-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/b158a8444810 Added tag jdk8u20-b07 for changeset f0ea4d3df129 ! .hgtags Changeset: e9ffa408f7af Author: amurillo Date: 2014-04-01 11:12 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/e9ffa408f7af Merge ! .hgtags Changeset: d5f0404d965f Author: katleman Date: 2014-04-02 09:31 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/d5f0404d965f Added tag jdk8u20-b08 for changeset e9ffa408f7af ! .hgtags Changeset: 5186bc5047c1 Author: amurillo Date: 2014-04-04 09:49 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/5186bc5047c1 Merge Changeset: 4d73f1e99f97 Author: amurillo Date: 2014-04-04 09:49 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/4d73f1e99f97 Added tag hs25.20-b09 for changeset 5186bc5047c1 ! .hgtags Changeset: eb82175e7fbb Author: amurillo Date: 2014-04-04 09:54 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/eb82175e7fbb 8039291: new hotspot build - hs25.20-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5cf196cc5405 Author: dbuck Date: 2014-04-05 23:38 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/5cf196cc5405 8026334: hs_err improvement: Print elapsed time in a humanly readable format Reviewed-by: coleenp, dsamersoff Contributed-by: masato.yoshida at oracle.com ! src/share/vm/runtime/os.cpp Changeset: fd8ddf2d2f6b Author: pliden Date: 2014-04-03 10:39 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/fd8ddf2d2f6b 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with unexpected memory usage Reviewed-by: jmasa, sjohanss ! test/gc/g1/TestStringDeduplicationTools.java Changeset: 14bd75c9dbfa Author: jwilhelm Date: 2014-04-03 16:20 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/14bd75c9dbfa 8039089: List verification enabled in product builds Summary: Replaced the verification call to a conditional one that only runs verification in debug builds. Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp Changeset: 3ef5c627634a Author: amurillo Date: 2014-04-07 22:13 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/3ef5c627634a 8039392: Make jdk8u20 the default jprt release for hs25.20 Reviewed-by: kvn, dholmes ! make/jprt.properties Changeset: 81d7a4b28dc5 Author: neugens Date: 2014-04-08 14:55 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/81d7a4b28dc5 8036619: Shark: add LLVM 3.4 support Reviewed-by: twisti, kvn ! make/linux/makefiles/zeroshark.make ! src/share/vm/shark/llvmHeaders.hpp ! src/share/vm/shark/sharkMemoryManager.cpp ! src/share/vm/shark/sharkMemoryManager.hpp Changeset: 8847586c9037 Author: vkempik Date: 2014-04-03 17:49 +0400 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/8847586c9037 8016302: Change type of the number of GC workers to unsigned int (2) Reviewed-by: tschatzl, jwilhelm ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1HotCardCache.cpp ! src/share/vm/gc_implementation/g1/g1HotCardCache.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 21dd1c827123 Author: kevinw Date: 2014-04-02 18:40 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/21dd1c827123 8033696: "assert(thread != NULL) failed: just checking" due to Thread::current() and JNI pthread interaction Reviewed-by: dholmes, dsamersoff Contributed-by: andreas.eriksson at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/runtime/vmThread.cpp Changeset: 58fab66a8297 Author: kevinw Date: 2014-04-09 03:48 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/58fab66a8297 Merge Changeset: a57ba009d4dc Author: roland Date: 2014-02-27 09:37 +0100 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/a57ba009d4dc 8032011: nsk/stress/jck60/jck60022 crashes in src\share\vm\runtime\synchronizer.cpp:239 Summary: biased locking's revoke_bias locks monitor in compiled frame with eliminated lock Reviewed-by: kvn, iveresov ! src/share/vm/runtime/biasedLocking.cpp + test/compiler/uncommontrap/TestLockEliminatedAtDeopt.java Changeset: 6048424d3865 Author: goetz Date: 2014-04-10 04:07 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/6048424d3865 8038201: Clean up misleading usage of malloc() in init_system_properties_values() Summary: Remove the misleading malloc macro and cleanup the code Reviewed-by: dsamersoff, kvn Contributed-by: goetz.lindenmaier at sap.com ! src/cpu/ppc/vm/templateInterpreter_ppc.cpp ! src/os/aix/vm/os_aix.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 526acaf3626f Author: kvn Date: 2014-04-09 11:18 -0700 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/526acaf3626f 8038939: Some options related to RTM locking optimization works inconsistently Summary: Switch UseRTMXendForLockBusy flag ON by default and change code to retry RTM locking on lock busy condition by default. Reviewed-by: roland ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp Changeset: 2100bf712e2a Author: goetz Date: 2014-04-03 12:37 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/stage/hotspot/rev/2100bf712e2a 8039146: Fix 64-bit store to int JNIHandleBlock::_top Reviewed-by: coleenp, kvn ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp From vladimir.kozlov at oracle.com Fri Apr 11 02:53:48 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Apr 2014 19:53:48 -0700 Subject: A last sync of stage? In-Reply-To: <53347F0D.2060408@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA7EE4@DEWDFEMB12A.global.corp.sap> <53232CDD.2030801@oracle.com> <5323484F.2000408@oracle.com> <53332DA3.4070408@oracle.com> <53347F0D.2060408@oracle.com> Message-ID: <5347593C.7090909@oracle.com> Hi, I synced 8u into ppc-aix stage repo. It includes all remaining fixes now. Please, verify that it good and we can freeze it. Regards, Vladimir On 3/27/14 12:42 PM, Vladimir Kozlov wrote: > Thank you, Volker > > I backported both 8035970 and 8035396 fixes. > We have only 3 issues left, I think, before we can freeze ppc-aix-port/stage: > > 8036767 PPC64: Support for little endian execution model > 8038201: Clean up misleading usage of malloc() in init_system_properties_values() > 8038498: Fix includes and C inlining after 8035330 > > Regards, > Vladimir > > On 3/27/14 8:04 AM, Volker Simonis wrote: >> Hi Vladimir, >> >> thanks for doing the sync. After this sync we need to downport the >> additional change "8035970: PPC64: fix ad file after 8027754: Enable >> loop optimizations for loops with MathExact": >> >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7e8e4d1a41d6 >> https://bugs.openjdk.java.net/browse/JDK-8035970 >> >> And please also don't forget to push "8035396: Introduce accessor for >> tmp_oop in frame" to stage (it is needed for the PPC64 template >> interpreter). You wanted to do it before but there were some problems >> with the closed repositories that time. >> >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/78112be27ba0 >> https://bugs.openjdk.java.net/browse/JDK-8035396 >> http://cr.openjdk.java.net/~goetz/webrevs/8035396-1-tmpOop/ >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012643.html >> >> I have just checked that both these changes apply cleanly to the >> current stage repository. >> >> Thank you and best regards, >> Volker >> >> >> On Wed, Mar 26, 2014 at 8:42 PM, Vladimir Kozlov >> wrote: >>> I synced jdk8u/hs-dev into ppc-aix-port/stage today. I pushed 8034797 too as >>> part of sync. >>> >>> I think it will be the last sync. Please, check that everything is okay for >>> you. >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 3/14/14 11:19 AM, Vladimir Kozlov wrote: >>>> >>>> Got it, I need to backport only 8035423 after sync today. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 3/14/14 9:46 AM, Volker Simonis wrote: >>>>> >>>>> Hi, >>>>> >>>>> I think what Goetz was trying to say is that if you would currently >>>>> sync with jdk8u-dev you'll need to also push 8035423 ("AIX: Fix >>>>> os::get_default_process_handle() in os_aix.cpp after 8031968" from >>>>> jdk9/jdk9/hotspot to stage because 8035423 fixes 8031968 which will >>>>> come from jdk8u-dev into stage. >>>>> >>>>> If you do the push later and jdk8u-dev already contains 8028280 >>>>> (currently it is only in hs-dev) youll also need to push 8034797 from >>>>> jdk9/jdk9/hotspot to stage for the same reason. >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> On Fri, Mar 14, 2014 at 5:22 PM, Vladimir Kozlov >>>>> wrote: >>>>>> >>>>>> I tried to do sync yesterday but JPRT did not behave well. I will try it >>>>>> again today. >>>>>> >>>>>> Please, clarify which fix I need to push where. Sorry, I don't get >>>>>> what you >>>>>> said. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> >>>>>> On 3/14/14 7:54 AM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>> >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> I think it would make sense to sync stage a last time, what >>>>>>> >>>>>>> do you think? The last sync was two weeks ago. If the date >>>>>>> >>>>>>> of 21^st is met, we don?t need another I would guess. >>>>>>> >>>>>>> >>>>>>> Two changes were downported that require fixes in the port: >>>>>>> >>>>>>> I saw 8031968 in jdk8u-dev and hs-dev. This requires >>>>>>> >>>>>>> 8035423: AIX: Fix os::get_default_process_handle() in >>>>>>> os_aix.cpp >>>>>>> after 8031968 >>>>>>> >>>>>>> 8028280 so far is only in hs-dev, which requires >>>>>>> >>>>>>> 8034797: AIX: Fix os::naked_short_sleep() in os_aix.cpp after >>>>>>> 8028280 >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Goetz. >>>>>>> >>>>>> >>> From asmundak at google.com Fri Apr 11 03:54:02 2014 From: asmundak at google.com (Alexander Smundak) Date: Thu, 10 Apr 2014 20:54:02 -0700 Subject: [7u] RFR(M): 8036767 : PPC64: Support for little endian execution model Message-ID: This set of patches is the backport of the corresponding changes for the OpenJDK9 (see http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/09edc8e9fa4d). Additional changes were required in the build machinery for corba/, jdk/ and langtools/ repositories. http://cr.openjdk.java.net/~asmundak/8036767.7u/corba/webrev.00 http://cr.openjdk.java.net/~asmundak/8036767.7u/hotspot/webrev.00 http://cr.openjdk.java.net/~asmundak/8036767.7u/jdk/webrev.00 http://cr.openjdk.java.net/~asmundak/8036767.7u/langtools/webrev.00 Sasha From volker.simonis at gmail.com Fri Apr 11 13:06:31 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Apr 2014 15:06:31 +0200 Subject: A last sync of stage? In-Reply-To: <5347593C.7090909@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA7EE4@DEWDFEMB12A.global.corp.sap> <53232CDD.2030801@oracle.com> <5323484F.2000408@oracle.com> <53332DA3.4070408@oracle.com> <53347F0D.2060408@oracle.com> <5347593C.7090909@oracle.com> Message-ID: On Fri, Apr 11, 2014 at 4:53 AM, Vladimir Kozlov wrote: > Hi, > > I synced 8u into ppc-aix stage repo. It includes all remaining fixes now. > Please, verify that it good and we can freeze it. > > Hi Vladimir, one could really think you?re crazy about finally freezing the stage repo:) I've just tested with the last changes and everything looks fine. Tremendous thanks for all your help (especially for such boring tasks like keeping our staging repositories in sync). @Iris: could you please switch the http://hg.openjdk.java.net/ppc-aix-port/stage forest to read-only mode. Regards, Volker > Regards, > Vladimir > > > On 3/27/14 12:42 PM, Vladimir Kozlov wrote: > >> Thank you, Volker >> >> I backported both 8035970 and 8035396 fixes. >> We have only 3 issues left, I think, before we can freeze >> ppc-aix-port/stage: >> >> 8036767 PPC64: Support for little endian execution model >> 8038201: Clean up misleading usage of malloc() in >> init_system_properties_values() >> 8038498: Fix includes and C inlining after 8035330 >> >> Regards, >> Vladimir >> >> On 3/27/14 8:04 AM, Volker Simonis wrote: >> >>> Hi Vladimir, >>> >>> thanks for doing the sync. After this sync we need to downport the >>> additional change "8035970: PPC64: fix ad file after 8027754: Enable >>> loop optimizations for loops with MathExact": >>> >>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7e8e4d1a41d6 >>> https://bugs.openjdk.java.net/browse/JDK-8035970 >>> >>> And please also don't forget to push "8035396: Introduce accessor for >>> tmp_oop in frame" to stage (it is needed for the PPC64 template >>> interpreter). You wanted to do it before but there were some problems >>> with the closed repositories that time. >>> >>> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/78112be27ba0 >>> https://bugs.openjdk.java.net/browse/JDK-8035396 >>> http://cr.openjdk.java.net/~goetz/webrevs/8035396-1-tmpOop/ >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014- >>> February/012643.html >>> >>> I have just checked that both these changes apply cleanly to the >>> current stage repository. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> On Wed, Mar 26, 2014 at 8:42 PM, Vladimir Kozlov >>> wrote: >>> >>>> I synced jdk8u/hs-dev into ppc-aix-port/stage today. I pushed 8034797 >>>> too as >>>> part of sync. >>>> >>>> I think it will be the last sync. Please, check that everything is okay >>>> for >>>> you. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On 3/14/14 11:19 AM, Vladimir Kozlov wrote: >>>> >>>>> >>>>> Got it, I need to backport only 8035423 after sync today. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 3/14/14 9:46 AM, Volker Simonis wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I think what Goetz was trying to say is that if you would currently >>>>>> sync with jdk8u-dev you'll need to also push 8035423 ("AIX: Fix >>>>>> os::get_default_process_handle() in os_aix.cpp after 8031968" from >>>>>> jdk9/jdk9/hotspot to stage because 8035423 fixes 8031968 which will >>>>>> come from jdk8u-dev into stage. >>>>>> >>>>>> If you do the push later and jdk8u-dev already contains 8028280 >>>>>> (currently it is only in hs-dev) youll also need to push 8034797 from >>>>>> jdk9/jdk9/hotspot to stage for the same reason. >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>> On Fri, Mar 14, 2014 at 5:22 PM, Vladimir Kozlov >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> I tried to do sync yesterday but JPRT did not behave well. I will >>>>>>> try it >>>>>>> again today. >>>>>>> >>>>>>> Please, clarify which fix I need to push where. Sorry, I don't get >>>>>>> what you >>>>>>> said. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> >>>>>>> On 3/14/14 7:54 AM, Lindenmaier, Goetz wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> I think it would make sense to sync stage a last time, what >>>>>>>> >>>>>>>> do you think? The last sync was two weeks ago. If the date >>>>>>>> >>>>>>>> of 21^st is met, we don?t need another I would guess. >>>>>>>> >>>>>>>> >>>>>>>> Two changes were downported that require fixes in the port: >>>>>>>> >>>>>>>> I saw 8031968 in jdk8u-dev and hs-dev. This requires >>>>>>>> >>>>>>>> 8035423: AIX: Fix os::get_default_process_handle() in >>>>>>>> os_aix.cpp >>>>>>>> after 8031968 >>>>>>>> >>>>>>>> 8028280 so far is only in hs-dev, which requires >>>>>>>> >>>>>>>> 8034797: AIX: Fix os::naked_short_sleep() in os_aix.cpp >>>>>>>> after >>>>>>>> 8028280 >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Apr 11 13:46:08 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Apr 2014 15:46:08 +0200 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: Hi Jonathan, thank you for fixing all the remaining issues. From my point of view this change looks good now. @Masayoshi: can I please get a final approval from you for pushing the change? I also want to downport this to 8u-dev but I don't think that's a big deal as this only touches AX code. Thank you and best regards, Volker On Thu, Apr 10, 2014 at 11:44 AM, Jonathan Lu wrote: > Hi Volker, > > Thanks a lot for your comments, I've made another patch, > > http://cr.openjdk.java.net/~luchsh/JDK-8Masayoshi034220.v4/ > > > On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis wrote: > >> Hi Jonathan, >> >> sorry, but I found a few more issues: >> >> - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise >> somebody could easily crash the VM by specifying a TZ with more than >> 100 characters. >> > > Right, I've fix it by using strncpy, and also updated another usage of > strcmp(). > > > >> >> - you can delete the lines 871-872 because the variables are actually >> not used and you can also remove the handling for "timezone == 0" >> because that is actually done in getGMTOffsetID() anyway. >> > > Nice catch, have deleted those in latest patch. > > >> >> - could you please avoid the usage of strtok. It is not intended for >> usage in a multithreaded environment (see for example "man strtok" on >> AIX). strtok_r is probably overkill, but you could use for example >> strchr. >> > > I've changed it to strtok_r in this patch, > although strtok was only used once here, it may still impact other > threads. > > >> did you check the build on Windows? >> > > Yes, both patches got built on Windows. > > >> >> Thank you and best regards, >> Volker >> >> >> On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu >> wrote: >> > Hi Volker, Masayoshi, >> > >> > I made another patch which fixed the problems mentioned in last mail, >> > >> > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ >> > >> > Could you pls help to take a look? >> > >> > Many thanks >> > Jonathan >> > >> > >> > >> > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu > > >> > wrote: >> >> >> >> Hi Volker, >> >> >> >> >> >> On 2014?04?02? 23:07, Volker Simonis wrote: >> >> >> >> Hi Jonathan, >> >> >> >> thanks for updating the change. Please find my comments inline: >> >> >> >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu > > >> >> wrote: >> >> >> >> Hi Volker, Masayoshi, >> >> >> >> Thanks a lot for your review, here's the updated patch, could you pls >> take >> >> a >> >> look? >> >> >> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ >> >> >> >> >> >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis < >> volker.simonis at gmail.com> >> >> wrote: >> >> >> >> Hi Jonathan, >> >> >> >> thanks for doing this change. Please find some comments below: >> >> >> >> 1. please update the copyright year to 2014 in every file you touch >> >> >> >> Updated in new patch. >> >> >> >> 2. in CopyFiles.gmk you can simplify the change by joining the windows >> >> and aix cases because on Windows OPENJDK_TARGET_OS is the same like >> >> OPENJDK_TARGET_OS_API_DIR. So you can write: >> >> >> >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) >> >> >> >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib >> >> >> >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings >> >> $(call install-file) >> >> >> >> COPY_FILES += $(LIBDIR)/tzmappings >> >> >> >> endif >> >> >> >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is >> >> 'solaris' >> >> as I observed on my AIX box, >> >> solaris/lib is not the directory where tzmappings was stored for AIX. >> >> So I'm keeping this change, please fix me if I was wrong about the >> config. >> >> >> >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the >> >> construction of TZMAPPINGS_SRC as shown in the code snippet above. >> >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX >> >> and that should be just enough here. >> >> >> >> >> >> That's right, let me try that and also build/test on Windows platform. >> >> >> >> >> >> 3. regarding the changes proposed by Masayoshi: I agree that we should >> >> put the AIX timezone mapping code in its own function, but I don't >> >> think that getPlatformTimeZoneID() would be the right place. As far as >> >> I understand, getPlatformTimeZoneID() is used to get a platform time >> >> zone id if the environment variable "TZ" is not set. I don't know a >> >> way how this could be done on AIX (@Jonathan: maybe you know?). If >> >> there would be a way to get the time zone from some system files or >> >> so, then we should put this code into the AIX version of >> >> getPlatformTimeZoneID(). >> >> >> >> I guess we may try to use /etc/envrionment file, which is basic setting >> >> for >> >> all processes, >> >> see >> >> >> >> >> http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm >> >> The implementation of getPlatformTimeZoneID() has been updated. >> >> >> >> That's good! >> >> >> >> But the current AIX code contributed by Jonathan, actually uses the >> >> time zone id from the "TZ" environment variable and just maps it to a >> >> Java compatible time zone id. So I'd suggest to refactor this code >> >> into a function like for example "static const char* >> >> mapPlatformToJavaTimzone(const char* tz)" and call that from >> >> findJavaTZ_md(). I think that would make the code easier to >> >> understand. >> >> >> >> Agree, and have split the code into a separate static method to do the >> >> mapping work. >> >> >> >> Good. But there's still one error in findJavaTZ_md(): >> >> >> >> 706 #ifdef _AIX >> >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); >> >> 708 #endif >> >> >> >> This should read: >> >> >> >> 706 #ifdef _AIX >> >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, javatz); >> >> 708 #endif >> >> >> >> because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came >> >> from getPlatformTimeZoneID(). >> >> >> >> >> >> Right, but with the second approach, there may be a minor memory leak >> >> here, >> >> as javatz was not freed before being overwritten on AIX. will post >> another >> >> patch on this soon. >> >> >> >> >> >> With the above fixed I'll push this one we get one more review from a >> >> reviewer (I'm currently not an official reviewer). >> >> >> >> Regards, >> >> Volker >> >> >> >> >> >> @Masayoshi: what do you think, would you agree with such a solution. >> >> >> >> 4. I agree with Masayoshi that you should use the existing >> >> getGMTOffsetID() >> >> >> >> Updated in new patch to eliminate duplication. >> >> >> >> 5. Please notice that your change breaks all Unix builds except AIX >> >> because of: >> >> >> >> 759 } >> >> 760 tzerr: >> >> 761 if (javatz == NULL) { >> >> 762 time_t offset; >> >> ... >> >> 782 } >> >> 783 #endif >> >> >> >> I think that should read: >> >> >> >> 759 >> >> 760 tzerr: >> >> 761 if (javatz == NULL) { >> >> 762 time_t offset; >> >> ... >> >> 782 } >> >> 783 #endif >> >> 784 } >> >> >> >> Refactoring the code in an extra function will make that error more >> >> evident anyway. >> >> >> >> But please always build at least on one different platform (i.e. >> >> Linux) to prevent such errors in the future. >> >> >> >> My fault, sorry for the failure, should take no chance after any manual >> >> alteration. >> >> >> >> Regards, >> >> Volker >> >> >> >> >> >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu >> >> wrote: >> >> >> >> Hi Jonathan, >> >> >> >> The AIX specific code looks OK to me. But I'd suggest the code be moved >> >> to >> >> getPlatformTimeZoneID() for AIX, which just returns NULL currently. >> Also >> >> there's a function for producing a fallback ID in "GMT?hh:mm", >> >> getGMTOffsetID() which can be called in tzerr. >> >> >> >> Thanks, >> >> Masayoshi >> >> >> >> >> >> On 3/26/2014 3:47 PM, Jonathan Lu wrote: >> >> >> >> Hi ppc-aix-port-dev, core-libs-dev, >> >> >> >> Here's a patch for JDK-8034220, >> >> >> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ >> >> >> >> It is trying to add the a more complete timezone mapping mechanism for >> >> AIX >> >> platform. >> >> the changes are primarily based on IBM's commercial JDK code, which >> >> includes: >> >> >> >> - A new timezone mapping file added under directory jdk/src/aix/lib/ >> >> - Code to parse above config file, changed file is >> >> src/solaris/native/java/util/TimeZone_md.c >> >> - And also makefile change in make/CopyFiles.gmk to copy the config >> >> file >> >> >> >> Could you pls help to review and give comments ? >> >> >> >> Cheers >> >> - Jonathan >> >> >> >> Many thanks >> >> Jonathan >> >> >> >> Regards >> >> Jonathan >> > >> > >> > > Regards > Jonathan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iris.clark at oracle.com Fri Apr 11 15:58:14 2014 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 11 Apr 2014 08:58:14 -0700 (PDT) Subject: A last sync of stage? In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CEA7EE4@DEWDFEMB12A.global.corp.sap> <53232CDD.2030801@oracle.com> <5323484F.2000408@oracle.com> <53332DA3.4070408@oracle.com> <53347F0D.2060408@oracle.com> <5347593C.7090909@oracle.com> Message-ID: <81467b76-b3b8-4752-9963-f44d9d63eb97@default> Hi, Volker. ? http://hg.openjdk.java.net/ppc-aix-port ? stage is now READ-ONLY.? ??Yea! ? Thanks, iris ? From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Friday, April 11, 2014 6:07 AM To: Vladimir Kozlov; Iris Clark Cc: Azeem Jiva; ppc-aix-port-dev at openjdk.java.net Subject: Re: A last sync of stage? ? ? On Fri, Apr 11, 2014 at 4:53 AM, Vladimir Kozlov wrote: Hi, I synced 8u into ppc-aix stage repo. It includes all remaining fixes now. Please, verify that it good and we can freeze it. ? Hi Vladimir, one could really think you?re crazy about finally freezing the stage repo:) I've just tested with the last changes and everything looks fine. Tremendous thanks for all your help (especially for such boring tasks like keeping our staging repositories in sync). @Iris: could you please switch the http://hg.openjdk.java.net/ppc-aix-port/stage forest to read-only mode. Regards, Volker ? Regards, Vladimir On 3/27/14 12:42 PM, Vladimir Kozlov wrote: Thank you, Volker I backported both 8035970 and 8035396 fixes. We have only 3 issues left, I think, before we can freeze ppc-aix-port/stage: 8036767 PPC64: Support for little endian execution model 8038201: Clean up misleading usage of malloc() in init_system_properties_values() 8038498: Fix includes and C inlining after 8035330 Regards, Vladimir On 3/27/14 8:04 AM, Volker Simonis wrote: Hi Vladimir, thanks for doing the sync. After this sync we need to downport the additional change "8035970: PPC64: fix ad file after 8027754: Enable loop optimizations for loops with MathExact": http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7e8e4d1a41d6 https://bugs.openjdk.java.net/browse/JDK-8035970 And please also don't forget to push "8035396: Introduce accessor for tmp_oop in frame" to stage (it is needed for the PPC64 template interpreter). You wanted to do it before but there were some problems with the closed repositories that time. http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/78112be27ba0 https://bugs.openjdk.java.net/browse/JDK-8035396 http://cr.openjdk.java.net/~goetz/webrevs/8035396-1-tmpOop/ http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012643.html I have just checked that both these changes apply cleanly to the current stage repository. Thank you and best regards, Volker On Wed, Mar 26, 2014 at 8:42 PM, Vladimir Kozlov wrote: I synced jdk8u/hs-dev into ppc-aix-port/stage today. I pushed 8034797 too as part of sync. I think it will be the last sync. Please, check that everything is okay for you. Thanks, Vladimir On 3/14/14 11:19 AM, Vladimir Kozlov wrote: Got it, I need to backport only 8035423 after sync today. Thanks, Vladimir On 3/14/14 9:46 AM, Volker Simonis wrote: Hi, I think what Goetz was trying to say is that if you would currently sync with jdk8u-dev you'll need to also push 8035423 ("AIX: Fix os::get_default_process_handle() in os_aix.cpp after 8031968" from jdk9/jdk9/hotspot to stage because 8035423 fixes 8031968 which will come from jdk8u-dev into stage. If you do the push later and jdk8u-dev already contains 8028280 (currently it is only in hs-dev) youll also need to push 8034797 from jdk9/jdk9/hotspot to stage for the same reason. Thank you and best regards, Volker On Fri, Mar 14, 2014 at 5:22 PM, Vladimir Kozlov wrote: I tried to do sync yesterday but JPRT did not behave well. I will try it again today. Please, clarify which fix I need to push where. Sorry, I don't get what you said. Thanks, Vladimir On 3/14/14 7:54 AM, Lindenmaier, Goetz wrote: Hi Vladimir, I think it would make sense to sync stage a last time, what do you think? ?The last sync was two weeks ago. ?If the date of 21^st is met, we don?t need another I would guess. Two changes were downported that require fixes in the port: I saw 8031968 in jdk8u-dev and hs-dev. ?This requires ? ? ? ? ? 8035423: AIX: Fix os::get_default_process_handle() in os_aix.cpp after 8031968 8028280 so far is only in hs-dev, which requires ? ? ? ? ? 8034797: AIX: Fix os::naked_short_sleep() in os_aix.cpp after 8028280 Best regards, ? ? ?Goetz. ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Apr 11 16:54:23 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Apr 2014 18:54:23 +0200 Subject: A last sync of stage? In-Reply-To: <81467b76-b3b8-4752-9963-f44d9d63eb97@default> References: <4295855A5C1DE049A61835A1887419CC2CEA7EE4@DEWDFEMB12A.global.corp.sap> <53232CDD.2030801@oracle.com> <5323484F.2000408@oracle.com> <53332DA3.4070408@oracle.com> <53347F0D.2060408@oracle.com> <5347593C.7090909@oracle.com> <81467b76-b3b8-4752-9963-f44d9d63eb97@default> Message-ID: Thanks a lot Iris! Without your great help this project would not have run so smoothly. Regards, Volker On Fri, Apr 11, 2014 at 5:58 PM, Iris Clark wrote: > Hi, Volker. > > > > http://hg.openjdk.java.net/ppc-aix-port > > > > stage is now READ-ONLY. Yea! > > > > Thanks, > > iris > > > > *From:* Volker Simonis [mailto:volker.simonis at gmail.com] > *Sent:* Friday, April 11, 2014 6:07 AM > *To:* Vladimir Kozlov; Iris Clark > *Cc:* Azeem Jiva; ppc-aix-port-dev at openjdk.java.net > *Subject:* Re: A last sync of stage? > > > > > > On Fri, Apr 11, 2014 at 4:53 AM, Vladimir Kozlov < > vladimir.kozlov at oracle.com> wrote: > > Hi, > > I synced 8u into ppc-aix stage repo. It includes all remaining fixes now. > Please, verify that it good and we can freeze it. > > > > Hi Vladimir, > > one could really think you?re crazy about finally freezing the stage repo:) > > I've just tested with the last changes and everything looks fine. > > Tremendous thanks for all your help (especially for such boring tasks like > keeping our staging repositories in sync). > > @Iris: could you please switch the > http://hg.openjdk.java.net/ppc-aix-port/stage forest to read-only mode. > > Regards, > > Volker > > > > Regards, > Vladimir > > > > On 3/27/14 12:42 PM, Vladimir Kozlov wrote: > > Thank you, Volker > > I backported both 8035970 and 8035396 fixes. > We have only 3 issues left, I think, before we can freeze > ppc-aix-port/stage: > > 8036767 PPC64: Support for little endian execution model > 8038201: Clean up misleading usage of malloc() in > init_system_properties_values() > 8038498: Fix includes and C inlining after 8035330 > > Regards, > Vladimir > > On 3/27/14 8:04 AM, Volker Simonis wrote: > > Hi Vladimir, > > thanks for doing the sync. After this sync we need to downport the > additional change "8035970: PPC64: fix ad file after 8027754: Enable > loop optimizations for loops with MathExact": > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7e8e4d1a41d6 > https://bugs.openjdk.java.net/browse/JDK-8035970 > > And please also don't forget to push "8035396: Introduce accessor for > tmp_oop in frame" to stage (it is needed for the PPC64 template > interpreter). You wanted to do it before but there were some problems > with the closed repositories that time. > > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/78112be27ba0 > https://bugs.openjdk.java.net/browse/JDK-8035396 > http://cr.openjdk.java.net/~goetz/webrevs/8035396-1-tmpOop/ > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012643.html > > I have just checked that both these changes apply cleanly to the > current stage repository. > > Thank you and best regards, > Volker > > > On Wed, Mar 26, 2014 at 8:42 PM, Vladimir Kozlov > wrote: > > I synced jdk8u/hs-dev into ppc-aix-port/stage today. I pushed 8034797 too > as > part of sync. > > I think it will be the last sync. Please, check that everything is okay for > you. > > Thanks, > Vladimir > > > On 3/14/14 11:19 AM, Vladimir Kozlov wrote: > > > Got it, I need to backport only 8035423 after sync today. > > Thanks, > Vladimir > > On 3/14/14 9:46 AM, Volker Simonis wrote: > > > Hi, > > I think what Goetz was trying to say is that if you would currently > sync with jdk8u-dev you'll need to also push 8035423 ("AIX: Fix > os::get_default_process_handle() in os_aix.cpp after 8031968" from > jdk9/jdk9/hotspot to stage because 8035423 fixes 8031968 which will > come from jdk8u-dev into stage. > > If you do the push later and jdk8u-dev already contains 8028280 > (currently it is only in hs-dev) youll also need to push 8034797 from > jdk9/jdk9/hotspot to stage for the same reason. > > Thank you and best regards, > Volker > > On Fri, Mar 14, 2014 at 5:22 PM, Vladimir Kozlov > wrote: > > > I tried to do sync yesterday but JPRT did not behave well. I will try it > again today. > > Please, clarify which fix I need to push where. Sorry, I don't get > what you > said. > > Thanks, > Vladimir > > > On 3/14/14 7:54 AM, Lindenmaier, Goetz wrote: > > > > Hi Vladimir, > > I think it would make sense to sync stage a last time, what > > do you think? The last sync was two weeks ago. If the date > > of 21^st is met, we don?t need another I would guess. > > > Two changes were downported that require fixes in the port: > > I saw 8031968 in jdk8u-dev and hs-dev. This requires > > 8035423: AIX: Fix os::get_default_process_handle() in > os_aix.cpp > after 8031968 > > 8028280 so far is only in hs-dev, which requires > > 8034797: AIX: Fix os::naked_short_sleep() in os_aix.cpp after > 8028280 > > Best regards, > > Goetz. > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From masayoshi.okutsu at oracle.com Mon Apr 14 06:03:17 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 14 Apr 2014 15:03:17 +0900 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> Message-ID: <534B7A25.7070800@oracle.com> Looks good to me. Thanks, Masayoshi On 4/11/2014 10:46 PM, Volker Simonis wrote: > Hi Jonathan, > > thank you for fixing all the remaining issues. From my point of view > this change looks good now. > > @Masayoshi: can I please get a final approval from you for pushing the > change? I also want to downport this to 8u-dev but I don't think > that's a big deal as this only touches AX code. > > Thank you and best regards, > Volker > > On Thu, Apr 10, 2014 at 11:44 AM, Jonathan Lu > > wrote: > > Hi Volker, > > Thanks a lot for your comments, I've made another patch, > > http://cr.openjdk.java.net/~luchsh/JDK-8Masayoshi034220.v4/ > > > > On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis > > wrote: > > Hi Jonathan, > > sorry, but I found a few more issues: > > - please use strncpy instead of strcpy in TimeZone_md.c:798 > otherwise > somebody could easily crash the VM by specifying a TZ with > more than > 100 characters. > > > Right, I've fix it by using strncpy, and also updated another > usage of strcmp(). > > > - you can delete the lines 871-872 because the variables are > actually > not used and you can also remove the handling for "timezone == 0" > because that is actually done in getGMTOffsetID() anyway. > > > Nice catch, have deleted those in latest patch. > > > - could you please avoid the usage of strtok. It is not > intended for > usage in a multithreaded environment (see for example "man > strtok" on > AIX). strtok_r is probably overkill, but you could use for example > strchr. > > > I've changed it to strtok_r in this patch, > although strtok was only used once here, it may still impact > other threads. > > > did you check the build on Windows? > > > Yes, both patches got built on Windows. > > > Thank you and best regards, > Volker > > > On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu > > > wrote: > > Hi Volker, Masayoshi, > > > > I made another patch which fixed the problems mentioned in > last mail, > > > > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ > > > > > Could you pls help to take a look? > > > > Many thanks > > Jonathan > > > > > > > > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu > > > > wrote: > >> > >> Hi Volker, > >> > >> > >> On 2014?04?02? 23:07, Volker Simonis wrote: > >> > >> Hi Jonathan, > >> > >> thanks for updating the change. Please find my comments inline: > >> > >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu > > > >> wrote: > >> > >> Hi Volker, Masayoshi, > >> > >> Thanks a lot for your review, here's the updated patch, > could you pls take > >> a > >> look? > >> > >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ > > >> > >> > >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis > > > >> wrote: > >> > >> Hi Jonathan, > >> > >> thanks for doing this change. Please find some comments below: > >> > >> 1. please update the copyright year to 2014 in every file > you touch > >> > >> Updated in new patch. > >> > >> 2. in CopyFiles.gmk you can simplify the change by joining > the windows > >> and aix cases because on Windows OPENJDK_TARGET_OS is the > same like > >> OPENJDK_TARGET_OS_API_DIR. So you can write: > >> > >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) > >> > >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib > >> > >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings > >> $(call install-file) > >> > >> COPY_FILES += $(LIBDIR)/tzmappings > >> > >> endif > >> > >> I've tried that approach before, but > OPENJDK_TARGET_OS_API_DIR is > >> 'solaris' > >> as I observed on my AIX box, > >> solaris/lib is not the directory where tzmappings was > stored for AIX. > >> So I'm keeping this change, please fix me if I was wrong > about the config. > >> > >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the > >> construction of TZMAPPINGS_SRC as shown in the code > snippet above. > >> OPENJDK_TARGET_OS is "windows" on Windows platforms and > "aix" on AIX > >> and that should be just enough here. > >> > >> > >> That's right, let me try that and also build/test on > Windows platform. > >> > >> > >> 3. regarding the changes proposed by Masayoshi: I agree > that we should > >> put the AIX timezone mapping code in its own function, but > I don't > >> think that getPlatformTimeZoneID() would be the right > place. As far as > >> I understand, getPlatformTimeZoneID() is used to get a > platform time > >> zone id if the environment variable "TZ" is not set. I > don't know a > >> way how this could be done on AIX (@Jonathan: maybe you > know?). If > >> there would be a way to get the time zone from some system > files or > >> so, then we should put this code into the AIX version of > >> getPlatformTimeZoneID(). > >> > >> I guess we may try to use /etc/envrionment file, which is > basic setting > >> for > >> all processes, > >> see > >> > >> > http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm > >> The implementation of getPlatformTimeZoneID() has been > updated. > >> > >> That's good! > >> > >> But the current AIX code contributed by Jonathan, actually > uses the > >> time zone id from the "TZ" environment variable and just > maps it to a > >> Java compatible time zone id. So I'd suggest to refactor > this code > >> into a function like for example "static const char* > >> mapPlatformToJavaTimzone(const char* tz)" and call that from > >> findJavaTZ_md(). I think that would make the code easier to > >> understand. > >> > >> Agree, and have split the code into a separate static > method to do the > >> mapping work. > >> > >> Good. But there's still one error in findJavaTZ_md(): > >> > >> 706 #ifdef _AIX > >> 707 javatz = > mapPlatformToJavaTimezone(java_home_dir, tz); > >> 708 #endif > >> > >> This should read: > >> > >> 706 #ifdef _AIX > >> 707 javatz = > mapPlatformToJavaTimezone(java_home_dir, javatz); > >> 708 #endif > >> > >> because in line 703 you free 'tz' via its alias 'freetz' if > 'tz' came > >> from getPlatformTimeZoneID(). > >> > >> > >> Right, but with the second approach, there may be a minor > memory leak > >> here, > >> as javatz was not freed before being overwritten on AIX. > will post another > >> patch on this soon. > >> > >> > >> With the above fixed I'll push this one we get one more > review from a > >> reviewer (I'm currently not an official reviewer). > >> > >> Regards, > >> Volker > >> > >> > >> @Masayoshi: what do you think, would you agree with such a > solution. > >> > >> 4. I agree with Masayoshi that you should use the existing > >> getGMTOffsetID() > >> > >> Updated in new patch to eliminate duplication. > >> > >> 5. Please notice that your change breaks all Unix builds > except AIX > >> because of: > >> > >> 759 } > >> 760 tzerr: > >> 761 if (javatz == NULL) { > >> 762 time_t offset; > >> ... > >> 782 } > >> 783 #endif > >> > >> I think that should read: > >> > >> 759 > >> 760 tzerr: > >> 761 if (javatz == NULL) { > >> 762 time_t offset; > >> ... > >> 782 } > >> 783 #endif > >> 784 } > >> > >> Refactoring the code in an extra function will make that > error more > >> evident anyway. > >> > >> But please always build at least on one different platform > (i.e. > >> Linux) to prevent such errors in the future. > >> > >> My fault, sorry for the failure, should take no chance > after any manual > >> alteration. > >> > >> Regards, > >> Volker > >> > >> > >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu > >> > wrote: > >> > >> Hi Jonathan, > >> > >> The AIX specific code looks OK to me. But I'd suggest the > code be moved > >> to > >> getPlatformTimeZoneID() for AIX, which just returns NULL > currently. Also > >> there's a function for producing a fallback ID in "GMT?hh:mm", > >> getGMTOffsetID() which can be called in tzerr. > >> > >> Thanks, > >> Masayoshi > >> > >> > >> On 3/26/2014 3:47 PM, Jonathan Lu wrote: > >> > >> Hi ppc-aix-port-dev, core-libs-dev, > >> > >> Here's a patch for JDK-8034220, > >> > >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ > > >> > >> It is trying to add the a more complete timezone mapping > mechanism for > >> AIX > >> platform. > >> the changes are primarily based on IBM's commercial JDK > code, which > >> includes: > >> > >> - A new timezone mapping file added under directory > jdk/src/aix/lib/ > >> - Code to parse above config file, changed file is > >> src/solaris/native/java/util/TimeZone_md.c > >> - And also makefile change in make/CopyFiles.gmk to copy > the config > >> file > >> > >> Could you pls help to review and give comments ? > >> > >> Cheers > >> - Jonathan > >> > >> Many thanks > >> Jonathan > >> > >> Regards > >> Jonathan > > > > > > > Regards > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Mon Apr 14 13:27:17 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 14 Apr 2014 15:27:17 +0200 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: <73613160-EF81-41E9-8112-0E078D6BB758@oracle.com> References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> <533B3174.5060301@oracle.com> <25AA6D2D-A229-4FF1-9CB6-C0C502D108D2@oracle.com> <533C34E1.7090801@oracle.com> <2347D3C4-1383-44F5-B64D-2501FE14212D@oracle.com> <5345C342.4040704@oracle.com> <73613160-EF81-41E9-8112-0E078D6BB758@oracle.com> Message-ID: <2E36A794-6EEA-4EAC-862C-D9C1E8DDD7CD@oracle.com> Here is a new webrev that implements Vladimir?s suggestion (use max stack in interpreter frame size computation): http://cr.openjdk.java.net/~roland/8032410/webrev.04/ The diff from the previous webrev: http://cr.openjdk.java.net/~roland/8032410/webrev.03-04/ Roland. On Apr 10, 2014, at 10:26 AM, Roland Westrelin wrote: > Hi Vladimir, > >>>> I tried to tell about this during review ;) I thought using (<=StackShadowPages) from 8026775 changes should touch it. >>> >>> Sorry Vladimir. I didn?t realize there could be a problem even before the end of the stack is reached. I should have read 8026775 more carefully. >>> >>>> Can you spend sometime and write down in bug report about all places where we do stack bang and how much pages we bang so we can see whole picture? >>>> >>>> I think we should bang all sequential pages and do the same in all places. Banging StackShadowPages or StackShadowPages+1 is secondary if we do the same in all places. >>> >>> Ready for some headaches? >>> >>> The interpreter: allocates the current frame and then stack bangs all pages at sp+1*page ? sp+StackShadowPages*page included >>> The compiler bangs (before my change): sp + StackShadowPages*page and the next frame_size/page_size pages >>> In the deopt blob we bang: sp (once the compiled frame is popped) +1 page ? sp+(StackShadowPages+1)*page and the next frame_size/page_size pages >>> >>> I talked with Mikael and the reason we bang up to (StackShadowPages+1)*page in the deopt blob is because in the interpreter, banging happens once the frame is set up. So banging up to StackShadowPages*page in the deopt blob with no frame pushed doesn?t bang as far as the interpreter would. >> >> So far I am following :) >> >>> >>> Let?s take an example with my change (no banging in the deopt blob) and if the compiler bangs at sp+StackShadowPages*page. I think something like this is possible: >>> Let?s say StackShadowPages=2 >>> >>> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P. The interpreter bangs P+1 and P+2. >> >> Do you mean when the frame is small we stay on the same page after the frame is allocated? Okay. > > Yes. > >> >>> 2) The interpreter calls a compiled method. The compiled method is entered with SP still in P but right before the boundary with the next page. The compiler bangs P+2. >> >> Could you remind me about your change? Does compiled code bangs all range from min(interpr_frame_size, comp_frame_size) to max(interpr_frame_size, comp_frame_size) plus StackShadowPages? Or only (max + StackShadowPages)? > > It bangs pages at sp + StackShadowPages*page_size and the next max(interpr_frame_size, comp_frame_size)/page_size pages if any. Before my change, the compiled code banged at sp + StackShadowPages*page_size and the next comp_frame_size/page_size pages if any > >> >>> 3) We deoptimize. We pop the frame. SP is in P right before the page boundary. The method has a lot of locals and the interpreter frame size is just below 1 page. After deoptimization SP is in P+1 right before the boundary. >> >> So SP is the same as on entry to the compiled method after the frame pop? > > Yes. > >> Do we touch all stack slots when we reconstruct Interpreter frame during deoptimization? Asking for a case when last slots are in next page and we don't touch it. > > I assume we do. > >> >>> 4) We?re at a call, push some arguments and SP moves to P+2 and we call a compiled method. The compiled method bang P+4. P+3 was never touched. >> >> Method's max_stack should take into account the space for output arguments. It need to be taking into account when we bang in compiled code. In 2) compiled code should have bang p+2 and p+3. > > Ok. That would work indeed. > >>> >>> Had the compiler banged at P+3 (StackShadowPages+1) in 2), there would be no problem in that example. But then another example with my change and if the compiler bangs at sp+(StackShadowPages+1)*page. Let?s say StackShadowPages=2. >>> >>> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P but right before the page boundary. The interpreter bangs P+1 and P+2. >>> 2) The interpreter pushes some arguments and we are now in P+1 and calls a compiled method. The compiler bangs P+4. P+3 was never touched. >>> >>> So that doesn?t work either. >>> >>> Wishing we had a whiteboard again? ;-) >> >> Yes and yes! >> >>> >>> Maybe the solution is for the compiler to bang at sp + StackShadowPages*page + (interpreter_frame_size % page) and the next interpreter_frame_size/page_size pages. That would mimic what the interpreter does and would work in both examples, above I think. interpreter_frame_size would have to not include what?s on the expression stack of the top frame to be as close as possible to the interpreter behavior. >> >> I don't see how you can determine "next interpreter_frame_size/page_size pages" >> >> As I said before if compiled code takes into account max stack size then first solution should work, I think. > > Let me try that. Thanks! > > Roland. > >> >> Thanks, >> Vladimir >> >> >>> >>> Roland. >>> >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/2/14 1:46 AM, Roland Westrelin wrote: >>>>>> The question is why you got EXCEPTION_ACCESS_VIOLATION for normal stack bang? May be it is 8026775 again when one page is skipped during banging. Windows requires sequential pages touche. >>>>> >>>>> I wasn?t aware of this requirement on windows. Thanks, Vladimir. >>>>> The interpreter bangs up to and including sp + StackShadowPages while the compiled code, with this change, bangs at sp + StackShadowPages + 1. So a page can be skipped and the requirement that all pages be touched sequentially cannot be guaranteed. So we either have to go back to banging at sp + StackShadowPages for the compiled code or enable the code that I pointed to in the signal on 32 bit. What do you think? >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 4/1/14 8:00 AM, Roland Westrelin wrote: >>>>>>> I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within the stack bounds). I noticed this code in the windows signal handler: >>>>>>> >>>>>>> #ifdef _WIN64 >>>>>>> // >>>>>>> // If it's a legal stack address map the entire region in >>>>>>> // >>>>>>> PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; >>>>>>> address addr = (address) exceptionRecord->ExceptionInformation[1]; >>>>>>> if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { >>>>>>> addr = (address)((uintptr_t)addr & >>>>>>> (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); >>>>>>> os::commit_memory((char *)addr, thread->stack_base() - addr, >>>>>>> !ExecMem); >>>>>>> return EXCEPTION_CONTINUE_EXECUTION; >>>>>>> } >>>>>>> else >>>>>>> #endif >>>>>>> >>>>>>> If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? >>>>>>> >>>>>>> Roland. From vladimir.kozlov at oracle.com Mon Apr 14 18:32:14 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Apr 2014 11:32:14 -0700 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: <2E36A794-6EEA-4EAC-862C-D9C1E8DDD7CD@oracle.com> References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> <533B3174.5060301@oracle.com> <25AA6D2D-A229-4FF1-9CB6-C0C502D108D2@oracle.com> <533C34E1.7090801@oracle.com> <2347D3C4-1383-44F5-B64D-2501FE14212D@oracle.com> <5345C342.4040704@oracle.com> <73613160-EF81-41E9-8112-0E078D6BB758@oracle.com> <2E36A794-6EEA-4EAC-862C-D9C1E8DDD7CD@oracle.com> Message-ID: <534C29AE.1080004@oracle.com> Looks fine to me. Thanks, Vladimir On 4/14/14 6:27 AM, Roland Westrelin wrote: > Here is a new webrev that implements Vladimir?s suggestion (use max stack in interpreter frame size computation): > > http://cr.openjdk.java.net/~roland/8032410/webrev.04/ > > The diff from the previous webrev: > > http://cr.openjdk.java.net/~roland/8032410/webrev.03-04/ > > Roland. > > On Apr 10, 2014, at 10:26 AM, Roland Westrelin wrote: > >> Hi Vladimir, >> >>>>> I tried to tell about this during review ;) I thought using (<=StackShadowPages) from 8026775 changes should touch it. >>>> >>>> Sorry Vladimir. I didn?t realize there could be a problem even before the end of the stack is reached. I should have read 8026775 more carefully. >>>> >>>>> Can you spend sometime and write down in bug report about all places where we do stack bang and how much pages we bang so we can see whole picture? >>>>> >>>>> I think we should bang all sequential pages and do the same in all places. Banging StackShadowPages or StackShadowPages+1 is secondary if we do the same in all places. >>>> >>>> Ready for some headaches? >>>> >>>> The interpreter: allocates the current frame and then stack bangs all pages at sp+1*page ? sp+StackShadowPages*page included >>>> The compiler bangs (before my change): sp + StackShadowPages*page and the next frame_size/page_size pages >>>> In the deopt blob we bang: sp (once the compiled frame is popped) +1 page ? sp+(StackShadowPages+1)*page and the next frame_size/page_size pages >>>> >>>> I talked with Mikael and the reason we bang up to (StackShadowPages+1)*page in the deopt blob is because in the interpreter, banging happens once the frame is set up. So banging up to StackShadowPages*page in the deopt blob with no frame pushed doesn?t bang as far as the interpreter would. >>> >>> So far I am following :) >>> >>>> >>>> Let?s take an example with my change (no banging in the deopt blob) and if the compiler bangs at sp+StackShadowPages*page. I think something like this is possible: >>>> Let?s say StackShadowPages=2 >>>> >>>> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P. The interpreter bangs P+1 and P+2. >>> >>> Do you mean when the frame is small we stay on the same page after the frame is allocated? Okay. >> >> Yes. >> >>> >>>> 2) The interpreter calls a compiled method. The compiled method is entered with SP still in P but right before the boundary with the next page. The compiler bangs P+2. >>> >>> Could you remind me about your change? Does compiled code bangs all range from min(interpr_frame_size, comp_frame_size) to max(interpr_frame_size, comp_frame_size) plus StackShadowPages? Or only (max + StackShadowPages)? >> >> It bangs pages at sp + StackShadowPages*page_size and the next max(interpr_frame_size, comp_frame_size)/page_size pages if any. Before my change, the compiled code banged at sp + StackShadowPages*page_size and the next comp_frame_size/page_size pages if any >> >>> >>>> 3) We deoptimize. We pop the frame. SP is in P right before the page boundary. The method has a lot of locals and the interpreter frame size is just below 1 page. After deoptimization SP is in P+1 right before the boundary. >>> >>> So SP is the same as on entry to the compiled method after the frame pop? >> >> Yes. >> >>> Do we touch all stack slots when we reconstruct Interpreter frame during deoptimization? Asking for a case when last slots are in next page and we don't touch it. >> >> I assume we do. >> >>> >>>> 4) We?re at a call, push some arguments and SP moves to P+2 and we call a compiled method. The compiled method bang P+4. P+3 was never touched. >>> >>> Method's max_stack should take into account the space for output arguments. It need to be taking into account when we bang in compiled code. In 2) compiled code should have bang p+2 and p+3. >> >> Ok. That would work indeed. >> >>>> >>>> Had the compiler banged at P+3 (StackShadowPages+1) in 2), there would be no problem in that example. But then another example with my change and if the compiler bangs at sp+(StackShadowPages+1)*page. Let?s say StackShadowPages=2. >>>> >>>> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P but right before the page boundary. The interpreter bangs P+1 and P+2. >>>> 2) The interpreter pushes some arguments and we are now in P+1 and calls a compiled method. The compiler bangs P+4. P+3 was never touched. >>>> >>>> So that doesn?t work either. >>>> >>>> Wishing we had a whiteboard again? ;-) >>> >>> Yes and yes! >>> >>>> >>>> Maybe the solution is for the compiler to bang at sp + StackShadowPages*page + (interpreter_frame_size % page) and the next interpreter_frame_size/page_size pages. That would mimic what the interpreter does and would work in both examples, above I think. interpreter_frame_size would have to not include what?s on the expression stack of the top frame to be as close as possible to the interpreter behavior. >>> >>> I don't see how you can determine "next interpreter_frame_size/page_size pages" >>> >>> As I said before if compiled code takes into account max stack size then first solution should work, I think. >> >> Let me try that. Thanks! >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> >>>> >>>> Roland. >>>> >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 4/2/14 1:46 AM, Roland Westrelin wrote: >>>>>>> The question is why you got EXCEPTION_ACCESS_VIOLATION for normal stack bang? May be it is 8026775 again when one page is skipped during banging. Windows requires sequential pages touche. >>>>>> >>>>>> I wasn?t aware of this requirement on windows. Thanks, Vladimir. >>>>>> The interpreter bangs up to and including sp + StackShadowPages while the compiled code, with this change, bangs at sp + StackShadowPages + 1. So a page can be skipped and the requirement that all pages be touched sequentially cannot be guaranteed. So we either have to go back to banging at sp + StackShadowPages for the compiled code or enable the code that I pointed to in the signal on 32 bit. What do you think? >>>>>> >>>>>> Roland. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 4/1/14 8:00 AM, Roland Westrelin wrote: >>>>>>>> I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within the stack bounds). I noticed this code in the windows signal handler: >>>>>>>> >>>>>>>> #ifdef _WIN64 >>>>>>>> // >>>>>>>> // If it's a legal stack address map the entire region in >>>>>>>> // >>>>>>>> PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; >>>>>>>> address addr = (address) exceptionRecord->ExceptionInformation[1]; >>>>>>>> if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { >>>>>>>> addr = (address)((uintptr_t)addr & >>>>>>>> (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); >>>>>>>> os::commit_memory((char *)addr, thread->stack_base() - addr, >>>>>>>> !ExecMem); >>>>>>>> return EXCEPTION_CONTINUE_EXECUTION; >>>>>>>> } >>>>>>>> else >>>>>>>> #endif >>>>>>>> >>>>>>>> If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? >>>>>>>> >>>>>>>> Roland. > From christian.thalinger at oracle.com Mon Apr 14 20:57:27 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Apr 2014 10:57:27 -1000 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: <2E36A794-6EEA-4EAC-862C-D9C1E8DDD7CD@oracle.com> References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> <533B3174.5060301@oracle.com> <25AA6D2D-A229-4FF1-9CB6-C0C502D108D2@oracle.com> <533C34E1.7090801@oracle.com> <2347D3C4-1383-44F5-B64D-2501FE14212D@oracle.com> <5345C342.4040704@oracle.com> <73613160-EF81-41E9-8112-0E078D6BB758@oracle.com> <2E36A794-6EEA-4EAC-862C-D9C1E8DDD7CD@oracle.com> Message-ID: Looks good. I hope it?s correct. On Apr 14, 2014, at 3:27 AM, Roland Westrelin wrote: > Here is a new webrev that implements Vladimir?s suggestion (use max stack in interpreter frame size computation): > > http://cr.openjdk.java.net/~roland/8032410/webrev.04/ > > The diff from the previous webrev: > > http://cr.openjdk.java.net/~roland/8032410/webrev.03-04/ > > Roland. > > On Apr 10, 2014, at 10:26 AM, Roland Westrelin wrote: > >> Hi Vladimir, >> >>>>> I tried to tell about this during review ;) I thought using (<=StackShadowPages) from 8026775 changes should touch it. >>>> >>>> Sorry Vladimir. I didn?t realize there could be a problem even before the end of the stack is reached. I should have read 8026775 more carefully. >>>> >>>>> Can you spend sometime and write down in bug report about all places where we do stack bang and how much pages we bang so we can see whole picture? >>>>> >>>>> I think we should bang all sequential pages and do the same in all places. Banging StackShadowPages or StackShadowPages+1 is secondary if we do the same in all places. >>>> >>>> Ready for some headaches? >>>> >>>> The interpreter: allocates the current frame and then stack bangs all pages at sp+1*page ? sp+StackShadowPages*page included >>>> The compiler bangs (before my change): sp + StackShadowPages*page and the next frame_size/page_size pages >>>> In the deopt blob we bang: sp (once the compiled frame is popped) +1 page ? sp+(StackShadowPages+1)*page and the next frame_size/page_size pages >>>> >>>> I talked with Mikael and the reason we bang up to (StackShadowPages+1)*page in the deopt blob is because in the interpreter, banging happens once the frame is set up. So banging up to StackShadowPages*page in the deopt blob with no frame pushed doesn?t bang as far as the interpreter would. >>> >>> So far I am following :) >>> >>>> >>>> Let?s take an example with my change (no banging in the deopt blob) and if the compiler bangs at sp+StackShadowPages*page. I think something like this is possible: >>>> Let?s say StackShadowPages=2 >>>> >>>> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P. The interpreter bangs P+1 and P+2. >>> >>> Do you mean when the frame is small we stay on the same page after the frame is allocated? Okay. >> >> Yes. >> >>> >>>> 2) The interpreter calls a compiled method. The compiled method is entered with SP still in P but right before the boundary with the next page. The compiler bangs P+2. >>> >>> Could you remind me about your change? Does compiled code bangs all range from min(interpr_frame_size, comp_frame_size) to max(interpr_frame_size, comp_frame_size) plus StackShadowPages? Or only (max + StackShadowPages)? >> >> It bangs pages at sp + StackShadowPages*page_size and the next max(interpr_frame_size, comp_frame_size)/page_size pages if any. Before my change, the compiled code banged at sp + StackShadowPages*page_size and the next comp_frame_size/page_size pages if any >> >>> >>>> 3) We deoptimize. We pop the frame. SP is in P right before the page boundary. The method has a lot of locals and the interpreter frame size is just below 1 page. After deoptimization SP is in P+1 right before the boundary. >>> >>> So SP is the same as on entry to the compiled method after the frame pop? >> >> Yes. >> >>> Do we touch all stack slots when we reconstruct Interpreter frame during deoptimization? Asking for a case when last slots are in next page and we don't touch it. >> >> I assume we do. >> >>> >>>> 4) We?re at a call, push some arguments and SP moves to P+2 and we call a compiled method. The compiled method bang P+4. P+3 was never touched. >>> >>> Method's max_stack should take into account the space for output arguments. It need to be taking into account when we bang in compiled code. In 2) compiled code should have bang p+2 and p+3. >> >> Ok. That would work indeed. >> >>>> >>>> Had the compiler banged at P+3 (StackShadowPages+1) in 2), there would be no problem in that example. But then another example with my change and if the compiler bangs at sp+(StackShadowPages+1)*page. Let?s say StackShadowPages=2. >>>> >>>> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P but right before the page boundary. The interpreter bangs P+1 and P+2. >>>> 2) The interpreter pushes some arguments and we are now in P+1 and calls a compiled method. The compiler bangs P+4. P+3 was never touched. >>>> >>>> So that doesn?t work either. >>>> >>>> Wishing we had a whiteboard again? ;-) >>> >>> Yes and yes! >>> >>>> >>>> Maybe the solution is for the compiler to bang at sp + StackShadowPages*page + (interpreter_frame_size % page) and the next interpreter_frame_size/page_size pages. That would mimic what the interpreter does and would work in both examples, above I think. interpreter_frame_size would have to not include what?s on the expression stack of the top frame to be as close as possible to the interpreter behavior. >>> >>> I don't see how you can determine "next interpreter_frame_size/page_size pages" >>> >>> As I said before if compiled code takes into account max stack size then first solution should work, I think. >> >> Let me try that. Thanks! >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> >>>> >>>> Roland. >>>> >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 4/2/14 1:46 AM, Roland Westrelin wrote: >>>>>>> The question is why you got EXCEPTION_ACCESS_VIOLATION for normal stack bang? May be it is 8026775 again when one page is skipped during banging. Windows requires sequential pages touche. >>>>>> >>>>>> I wasn?t aware of this requirement on windows. Thanks, Vladimir. >>>>>> The interpreter bangs up to and including sp + StackShadowPages while the compiled code, with this change, bangs at sp + StackShadowPages + 1. So a page can be skipped and the requirement that all pages be touched sequentially cannot be guaranteed. So we either have to go back to banging at sp + StackShadowPages for the compiled code or enable the code that I pointed to in the signal on 32 bit. What do you think? >>>>>> >>>>>> Roland. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 4/1/14 8:00 AM, Roland Westrelin wrote: >>>>>>>> I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within the stack bounds). I noticed this code in the windows signal handler: >>>>>>>> >>>>>>>> #ifdef _WIN64 >>>>>>>> // >>>>>>>> // If it's a legal stack address map the entire region in >>>>>>>> // >>>>>>>> PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; >>>>>>>> address addr = (address) exceptionRecord->ExceptionInformation[1]; >>>>>>>> if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { >>>>>>>> addr = (address)((uintptr_t)addr & >>>>>>>> (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); >>>>>>>> os::commit_memory((char *)addr, thread->stack_base() - addr, >>>>>>>> !ExecMem); >>>>>>>> return EXCEPTION_CONTINUE_EXECUTION; >>>>>>>> } >>>>>>>> else >>>>>>>> #endif >>>>>>>> >>>>>>>> If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? >>>>>>>> >>>>>>>> Roland. > From luchsh at linux.vnet.ibm.com Tue Apr 15 07:48:35 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Tue, 15 Apr 2014 15:48:35 +0800 Subject: Improve timezone mapping for AIX platform In-Reply-To: <534B7A25.7070800@oracle.com> References: <53329D98.6040002@oracle.com> <534B7A25.7070800@oracle.com> Message-ID: Hi Masayoshi, Volker, Thanks a lot for reviewing ! Is it OK for me to push the change into JDK9 directly ? or need another reviewer's approval ? Many thanks Jonathan On Mon, Apr 14, 2014 at 2:03 PM, Masayoshi Okutsu < masayoshi.okutsu at oracle.com> wrote: > Looks good to me. > > Thanks, > Masayoshi > > > On 4/11/2014 10:46 PM, Volker Simonis wrote: > > Hi Jonathan, > > thank you for fixing all the remaining issues. From my point of view this > change looks good now. > > @Masayoshi: can I please get a final approval from you for pushing the > change? I also want to downport this to 8u-dev but I don't think that's a > big deal as this only touches AX code. > > Thank you and best regards, > Volker > > On Thu, Apr 10, 2014 at 11:44 AM, Jonathan Lu wrote: > >> Hi Volker, >> >> Thanks a lot for your comments, I've made another patch, >> >> http://cr.openjdk.java.net/~luchsh/JDK-8Masayoshi034220.v4/ >> >> >> On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis wrote: >> >>> Hi Jonathan, >>> >>> sorry, but I found a few more issues: >>> >>> - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise >>> somebody could easily crash the VM by specifying a TZ with more than >>> 100 characters. >>> >> >> Right, I've fix it by using strncpy, and also updated another usage of >> strcmp(). >> >> >> >>> >>> - you can delete the lines 871-872 because the variables are actually >>> not used and you can also remove the handling for "timezone == 0" >>> because that is actually done in getGMTOffsetID() anyway. >>> >> >> Nice catch, have deleted those in latest patch. >> >> >>> >>> - could you please avoid the usage of strtok. It is not intended for >>> usage in a multithreaded environment (see for example "man strtok" on >>> AIX). strtok_r is probably overkill, but you could use for example >>> strchr. >>> >> >> I've changed it to strtok_r in this patch, >> although strtok was only used once here, it may still impact other >> threads. >> >> >>> did you check the build on Windows? >>> >> >> Yes, both patches got built on Windows. >> >> >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu >>> wrote: >>> > Hi Volker, Masayoshi, >>> > >>> > I made another patch which fixed the problems mentioned in last mail, >>> > >>> > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ >>> > >>> > Could you pls help to take a look? >>> > >>> > Many thanks >>> > Jonathan >>> > >>> > >>> > >>> > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu < >>> luchsh at linux.vnet.ibm.com> >>> > wrote: >>> >> >>> >> Hi Volker, >>> >> >>> >> >>> >> On 2014?04?02? 23:07, Volker Simonis wrote: >>> >> >>> >> Hi Jonathan, >>> >> >>> >> thanks for updating the change. Please find my comments inline: >>> >> >>> >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu < >>> luchsh at linux.vnet.ibm.com> >>> >> wrote: >>> >> >>> >> Hi Volker, Masayoshi, >>> >> >>> >> Thanks a lot for your review, here's the updated patch, could you pls >>> take >>> >> a >>> >> look? >>> >> >>> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ >>> >> >>> >> >>> >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis < >>> volker.simonis at gmail.com> >>> >> wrote: >>> >> >>> >> Hi Jonathan, >>> >> >>> >> thanks for doing this change. Please find some comments below: >>> >> >>> >> 1. please update the copyright year to 2014 in every file you touch >>> >> >>> >> Updated in new patch. >>> >> >>> >> 2. in CopyFiles.gmk you can simplify the change by joining the windows >>> >> and aix cases because on Windows OPENJDK_TARGET_OS is the same like >>> >> OPENJDK_TARGET_OS_API_DIR. So you can write: >>> >> >>> >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) >>> >> >>> >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib >>> >> >>> >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings >>> >> $(call install-file) >>> >> >>> >> COPY_FILES += $(LIBDIR)/tzmappings >>> >> >>> >> endif >>> >> >>> >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is >>> >> 'solaris' >>> >> as I observed on my AIX box, >>> >> solaris/lib is not the directory where tzmappings was stored for AIX. >>> >> So I'm keeping this change, please fix me if I was wrong about the >>> config. >>> >> >>> >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the >>> >> construction of TZMAPPINGS_SRC as shown in the code snippet above. >>> >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX >>> >> and that should be just enough here. >>> >> >>> >> >>> >> That's right, let me try that and also build/test on Windows >>> platform. >>> >> >>> >> >>> >> 3. regarding the changes proposed by Masayoshi: I agree that we should >>> >> put the AIX timezone mapping code in its own function, but I don't >>> >> think that getPlatformTimeZoneID() would be the right place. As far as >>> >> I understand, getPlatformTimeZoneID() is used to get a platform time >>> >> zone id if the environment variable "TZ" is not set. I don't know a >>> >> way how this could be done on AIX (@Jonathan: maybe you know?). If >>> >> there would be a way to get the time zone from some system files or >>> >> so, then we should put this code into the AIX version of >>> >> getPlatformTimeZoneID(). >>> >> >>> >> I guess we may try to use /etc/envrionment file, which is basic >>> setting >>> >> for >>> >> all processes, >>> >> see >>> >> >>> >> >>> http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm >>> >> The implementation of getPlatformTimeZoneID() has been updated. >>> >> >>> >> That's good! >>> >> >>> >> But the current AIX code contributed by Jonathan, actually uses the >>> >> time zone id from the "TZ" environment variable and just maps it to a >>> >> Java compatible time zone id. So I'd suggest to refactor this code >>> >> into a function like for example "static const char* >>> >> mapPlatformToJavaTimzone(const char* tz)" and call that from >>> >> findJavaTZ_md(). I think that would make the code easier to >>> >> understand. >>> >> >>> >> Agree, and have split the code into a separate static method to do the >>> >> mapping work. >>> >> >>> >> Good. But there's still one error in findJavaTZ_md(): >>> >> >>> >> 706 #ifdef _AIX >>> >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); >>> >> 708 #endif >>> >> >>> >> This should read: >>> >> >>> >> 706 #ifdef _AIX >>> >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, >>> javatz); >>> >> 708 #endif >>> >> >>> >> because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came >>> >> from getPlatformTimeZoneID(). >>> >> >>> >> >>> >> Right, but with the second approach, there may be a minor memory leak >>> >> here, >>> >> as javatz was not freed before being overwritten on AIX. will post >>> another >>> >> patch on this soon. >>> >> >>> >> >>> >> With the above fixed I'll push this one we get one more review from a >>> >> reviewer (I'm currently not an official reviewer). >>> >> >>> >> Regards, >>> >> Volker >>> >> >>> >> >>> >> @Masayoshi: what do you think, would you agree with such a solution. >>> >> >>> >> 4. I agree with Masayoshi that you should use the existing >>> >> getGMTOffsetID() >>> >> >>> >> Updated in new patch to eliminate duplication. >>> >> >>> >> 5. Please notice that your change breaks all Unix builds except AIX >>> >> because of: >>> >> >>> >> 759 } >>> >> 760 tzerr: >>> >> 761 if (javatz == NULL) { >>> >> 762 time_t offset; >>> >> ... >>> >> 782 } >>> >> 783 #endif >>> >> >>> >> I think that should read: >>> >> >>> >> 759 >>> >> 760 tzerr: >>> >> 761 if (javatz == NULL) { >>> >> 762 time_t offset; >>> >> ... >>> >> 782 } >>> >> 783 #endif >>> >> 784 } >>> >> >>> >> Refactoring the code in an extra function will make that error more >>> >> evident anyway. >>> >> >>> >> But please always build at least on one different platform (i.e. >>> >> Linux) to prevent such errors in the future. >>> >> >>> >> My fault, sorry for the failure, should take no chance after any >>> manual >>> >> alteration. >>> >> >>> >> Regards, >>> >> Volker >>> >> >>> >> >>> >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu >>> >> wrote: >>> >> >>> >> Hi Jonathan, >>> >> >>> >> The AIX specific code looks OK to me. But I'd suggest the code be >>> moved >>> >> to >>> >> getPlatformTimeZoneID() for AIX, which just returns NULL currently. >>> Also >>> >> there's a function for producing a fallback ID in "GMT?hh:mm", >>> >> getGMTOffsetID() which can be called in tzerr. >>> >> >>> >> Thanks, >>> >> Masayoshi >>> >> >>> >> >>> >> On 3/26/2014 3:47 PM, Jonathan Lu wrote: >>> >> >>> >> Hi ppc-aix-port-dev, core-libs-dev, >>> >> >>> >> Here's a patch for JDK-8034220, >>> >> >>> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ >>> >> >>> >> It is trying to add the a more complete timezone mapping mechanism for >>> >> AIX >>> >> platform. >>> >> the changes are primarily based on IBM's commercial JDK code, which >>> >> includes: >>> >> >>> >> - A new timezone mapping file added under directory jdk/src/aix/lib/ >>> >> - Code to parse above config file, changed file is >>> >> src/solaris/native/java/util/TimeZone_md.c >>> >> - And also makefile change in make/CopyFiles.gmk to copy the config >>> >> file >>> >> >>> >> Could you pls help to review and give comments ? >>> >> >>> >> Cheers >>> >> - Jonathan >>> >> >>> >> Many thanks >>> >> Jonathan >>> >> >>> >> Regards >>> >> Jonathan >>> > >>> > >>> >> >> Regards >> Jonathan >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Apr 15 08:48:33 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 15 Apr 2014 10:48:33 +0200 Subject: [7u] RFR(M): 8036767 : PPC64: Support for little endian execution model In-Reply-To: References: Message-ID: Hi Sasha, with your changes the build fails in jdk on non-ppc Linux because OPENJDK_TARGET_CPU_ENDIAN is not defined. Could you please also test your changes on other platforms than ppc (i.e. at least Linux/amd64 and Windows) in the future. Thank you and best regards, Volker On Fri, Apr 11, 2014 at 5:54 AM, Alexander Smundak wrote: > This set of patches is the backport of the corresponding changes for > the OpenJDK9 > (see http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/09edc8e9fa4d). > Additional changes were required in the build machinery for corba/, > jdk/ and langtools/ repositories. > > http://cr.openjdk.java.net/~asmundak/8036767.7u/corba/webrev.00 > http://cr.openjdk.java.net/~asmundak/8036767.7u/hotspot/webrev.00 > http://cr.openjdk.java.net/~asmundak/8036767.7u/jdk/webrev.00 > http://cr.openjdk.java.net/~asmundak/8036767.7u/langtools/webrev.00 > > Sasha From roland.westrelin at oracle.com Tue Apr 15 08:49:10 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 15 Apr 2014 10:49:10 +0200 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: <534C29AE.1080004@oracle.com> References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> <533B3174.5060301@oracle.com> <25AA6D2D-A229-4FF1-9CB6-C0C502D108D2@oracle.com> <533C34E1.7090801@oracle.com> <2347D3C4-1383-44F5-B64D-2501FE14212D@oracle.com> <5345C342.4040704@oracle.com> <73613160-EF81-41E9-8112-0E078D6BB758@oracle.com> <2E36A794-6EEA-4EAC-862C-D9C1E8DDD7CD@oracle.com> <534C29AE.1080004@oracle.com> Message-ID: <636DC42E-01FC-4E9A-8C57-9C30AB323EE6@oracle.com> Thanks Vladimir. Roland. On Apr 14, 2014, at 8:32 PM, Vladimir Kozlov wrote: > Looks fine to me. > > Thanks, > Vladimir > > On 4/14/14 6:27 AM, Roland Westrelin wrote: >> Here is a new webrev that implements Vladimir?s suggestion (use max stack in interpreter frame size computation): >> >> http://cr.openjdk.java.net/~roland/8032410/webrev.04/ >> >> The diff from the previous webrev: >> >> http://cr.openjdk.java.net/~roland/8032410/webrev.03-04/ >> >> Roland. >> >> On Apr 10, 2014, at 10:26 AM, Roland Westrelin wrote: >> >>> Hi Vladimir, >>> >>>>>> I tried to tell about this during review ;) I thought using (<=StackShadowPages) from 8026775 changes should touch it. >>>>> >>>>> Sorry Vladimir. I didn?t realize there could be a problem even before the end of the stack is reached. I should have read 8026775 more carefully. >>>>> >>>>>> Can you spend sometime and write down in bug report about all places where we do stack bang and how much pages we bang so we can see whole picture? >>>>>> >>>>>> I think we should bang all sequential pages and do the same in all places. Banging StackShadowPages or StackShadowPages+1 is secondary if we do the same in all places. >>>>> >>>>> Ready for some headaches? >>>>> >>>>> The interpreter: allocates the current frame and then stack bangs all pages at sp+1*page ? sp+StackShadowPages*page included >>>>> The compiler bangs (before my change): sp + StackShadowPages*page and the next frame_size/page_size pages >>>>> In the deopt blob we bang: sp (once the compiled frame is popped) +1 page ? sp+(StackShadowPages+1)*page and the next frame_size/page_size pages >>>>> >>>>> I talked with Mikael and the reason we bang up to (StackShadowPages+1)*page in the deopt blob is because in the interpreter, banging happens once the frame is set up. So banging up to StackShadowPages*page in the deopt blob with no frame pushed doesn?t bang as far as the interpreter would. >>>> >>>> So far I am following :) >>>> >>>>> >>>>> Let?s take an example with my change (no banging in the deopt blob) and if the compiler bangs at sp+StackShadowPages*page. I think something like this is possible: >>>>> Let?s say StackShadowPages=2 >>>>> >>>>> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P. The interpreter bangs P+1 and P+2. >>>> >>>> Do you mean when the frame is small we stay on the same page after the frame is allocated? Okay. >>> >>> Yes. >>> >>>> >>>>> 2) The interpreter calls a compiled method. The compiled method is entered with SP still in P but right before the boundary with the next page. The compiler bangs P+2. >>>> >>>> Could you remind me about your change? Does compiled code bangs all range from min(interpr_frame_size, comp_frame_size) to max(interpr_frame_size, comp_frame_size) plus StackShadowPages? Or only (max + StackShadowPages)? >>> >>> It bangs pages at sp + StackShadowPages*page_size and the next max(interpr_frame_size, comp_frame_size)/page_size pages if any. Before my change, the compiled code banged at sp + StackShadowPages*page_size and the next comp_frame_size/page_size pages if any >>> >>>> >>>>> 3) We deoptimize. We pop the frame. SP is in P right before the page boundary. The method has a lot of locals and the interpreter frame size is just below 1 page. After deoptimization SP is in P+1 right before the boundary. >>>> >>>> So SP is the same as on entry to the compiled method after the frame pop? >>> >>> Yes. >>> >>>> Do we touch all stack slots when we reconstruct Interpreter frame during deoptimization? Asking for a case when last slots are in next page and we don't touch it. >>> >>> I assume we do. >>> >>>> >>>>> 4) We?re at a call, push some arguments and SP moves to P+2 and we call a compiled method. The compiled method bang P+4. P+3 was never touched. >>>> >>>> Method's max_stack should take into account the space for output arguments. It need to be taking into account when we bang in compiled code. In 2) compiled code should have bang p+2 and p+3. >>> >>> Ok. That would work indeed. >>> >>>>> >>>>> Had the compiler banged at P+3 (StackShadowPages+1) in 2), there would be no problem in that example. But then another example with my change and if the compiler bangs at sp+(StackShadowPages+1)*page. Let?s say StackShadowPages=2. >>>>> >>>>> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P but right before the page boundary. The interpreter bangs P+1 and P+2. >>>>> 2) The interpreter pushes some arguments and we are now in P+1 and calls a compiled method. The compiler bangs P+4. P+3 was never touched. >>>>> >>>>> So that doesn?t work either. >>>>> >>>>> Wishing we had a whiteboard again? ;-) >>>> >>>> Yes and yes! >>>> >>>>> >>>>> Maybe the solution is for the compiler to bang at sp + StackShadowPages*page + (interpreter_frame_size % page) and the next interpreter_frame_size/page_size pages. That would mimic what the interpreter does and would work in both examples, above I think. interpreter_frame_size would have to not include what?s on the expression stack of the top frame to be as close as possible to the interpreter behavior. >>>> >>>> I don't see how you can determine "next interpreter_frame_size/page_size pages" >>>> >>>> As I said before if compiled code takes into account max stack size then first solution should work, I think. >>> >>> Let me try that. Thanks! >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>>> >>>>> Roland. >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 4/2/14 1:46 AM, Roland Westrelin wrote: >>>>>>>> The question is why you got EXCEPTION_ACCESS_VIOLATION for normal stack bang? May be it is 8026775 again when one page is skipped during banging. Windows requires sequential pages touche. >>>>>>> >>>>>>> I wasn?t aware of this requirement on windows. Thanks, Vladimir. >>>>>>> The interpreter bangs up to and including sp + StackShadowPages while the compiled code, with this change, bangs at sp + StackShadowPages + 1. So a page can be skipped and the requirement that all pages be touched sequentially cannot be guaranteed. So we either have to go back to banging at sp + StackShadowPages for the compiled code or enable the code that I pointed to in the signal on 32 bit. What do you think? >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 4/1/14 8:00 AM, Roland Westrelin wrote: >>>>>>>>> I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within the stack bounds). I noticed this code in the windows signal handler: >>>>>>>>> >>>>>>>>> #ifdef _WIN64 >>>>>>>>> // >>>>>>>>> // If it's a legal stack address map the entire region in >>>>>>>>> // >>>>>>>>> PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; >>>>>>>>> address addr = (address) exceptionRecord->ExceptionInformation[1]; >>>>>>>>> if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { >>>>>>>>> addr = (address)((uintptr_t)addr & >>>>>>>>> (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); >>>>>>>>> os::commit_memory((char *)addr, thread->stack_base() - addr, >>>>>>>>> !ExecMem); >>>>>>>>> return EXCEPTION_CONTINUE_EXECUTION; >>>>>>>>> } >>>>>>>>> else >>>>>>>>> #endif >>>>>>>>> >>>>>>>>> If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? >>>>>>>>> >>>>>>>>> Roland. >> From roland.westrelin at oracle.com Tue Apr 15 08:49:39 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 15 Apr 2014 10:49:39 +0200 Subject: RFR(L): 8032410: compiler/uncommontrap/TestStackBangRbp.java times out on Solaris-Sparc V9 In-Reply-To: References: <09C8FEED-84F2-4F1A-A845-5DC8A76CF80E@oracle.com> <531E62B6.1000708@oracle.com> <87pplslmlc.fsf@oracle.com> <531FA9EB.2090906@oracle.com> <1B57AAEA-FE0D-40FC-850D-DC1E4BCD75CB@oracle.com> <532399A2.8080209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8BEA@DEWDFEMB12A.global.corp.sap> <8256510E-9E2F-428E-95C5-1176F243A3F7@oracle.com> <532B9528.3050303@oracle.com> <9D17B838-7388-4C2C-9B8B-0B4B98DC15CD@oracle.com> <533B3174.5060301@oracle.com> <25AA6D2D-A229-4FF1-9CB6-C0C502D108D2@oracle.com> <533C34E1.7090801@oracle.com> <2347D3C4-1383-44F5-B64D-2501FE14212D@oracle.com> <5345C342.4040704@oracle.com> <73613160-EF81-41E9-8112-0E078D6BB758@oracle.com> <2E36A794-6EEA-4EAC-862C-D9C1E8DDD7CD@oracle.com> Message-ID: <6F4C6135-F89C-42AF-B4A3-19B2D326C2C4@oracle.com> > Looks good. I hope it?s correct. You?re not the only one. Thanks for the re-review. Roland. > > On Apr 14, 2014, at 3:27 AM, Roland Westrelin wrote: > >> Here is a new webrev that implements Vladimir?s suggestion (use max stack in interpreter frame size computation): >> >> http://cr.openjdk.java.net/~roland/8032410/webrev.04/ >> >> The diff from the previous webrev: >> >> http://cr.openjdk.java.net/~roland/8032410/webrev.03-04/ >> >> Roland. >> >> On Apr 10, 2014, at 10:26 AM, Roland Westrelin wrote: >> >>> Hi Vladimir, >>> >>>>>> I tried to tell about this during review ;) I thought using (<=StackShadowPages) from 8026775 changes should touch it. >>>>> >>>>> Sorry Vladimir. I didn?t realize there could be a problem even before the end of the stack is reached. I should have read 8026775 more carefully. >>>>> >>>>>> Can you spend sometime and write down in bug report about all places where we do stack bang and how much pages we bang so we can see whole picture? >>>>>> >>>>>> I think we should bang all sequential pages and do the same in all places. Banging StackShadowPages or StackShadowPages+1 is secondary if we do the same in all places. >>>>> >>>>> Ready for some headaches? >>>>> >>>>> The interpreter: allocates the current frame and then stack bangs all pages at sp+1*page ? sp+StackShadowPages*page included >>>>> The compiler bangs (before my change): sp + StackShadowPages*page and the next frame_size/page_size pages >>>>> In the deopt blob we bang: sp (once the compiled frame is popped) +1 page ? sp+(StackShadowPages+1)*page and the next frame_size/page_size pages >>>>> >>>>> I talked with Mikael and the reason we bang up to (StackShadowPages+1)*page in the deopt blob is because in the interpreter, banging happens once the frame is set up. So banging up to StackShadowPages*page in the deopt blob with no frame pushed doesn?t bang as far as the interpreter would. >>>> >>>> So far I am following :) >>>> >>>>> >>>>> Let?s take an example with my change (no banging in the deopt blob) and if the compiler bangs at sp+StackShadowPages*page. I think something like this is possible: >>>>> Let?s say StackShadowPages=2 >>>>> >>>>> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P. The interpreter bangs P+1 and P+2. >>>> >>>> Do you mean when the frame is small we stay on the same page after the frame is allocated? Okay. >>> >>> Yes. >>> >>>> >>>>> 2) The interpreter calls a compiled method. The compiled method is entered with SP still in P but right before the boundary with the next page. The compiler bangs P+2. >>>> >>>> Could you remind me about your change? Does compiled code bangs all range from min(interpr_frame_size, comp_frame_size) to max(interpr_frame_size, comp_frame_size) plus StackShadowPages? Or only (max + StackShadowPages)? >>> >>> It bangs pages at sp + StackShadowPages*page_size and the next max(interpr_frame_size, comp_frame_size)/page_size pages if any. Before my change, the compiled code banged at sp + StackShadowPages*page_size and the next comp_frame_size/page_size pages if any >>> >>>> >>>>> 3) We deoptimize. We pop the frame. SP is in P right before the page boundary. The method has a lot of locals and the interpreter frame size is just below 1 page. After deoptimization SP is in P+1 right before the boundary. >>>> >>>> So SP is the same as on entry to the compiled method after the frame pop? >>> >>> Yes. >>> >>>> Do we touch all stack slots when we reconstruct Interpreter frame during deoptimization? Asking for a case when last slots are in next page and we don't touch it. >>> >>> I assume we do. >>> >>>> >>>>> 4) We?re at a call, push some arguments and SP moves to P+2 and we call a compiled method. The compiled method bang P+4. P+3 was never touched. >>>> >>>> Method's max_stack should take into account the space for output arguments. It need to be taking into account when we bang in compiled code. In 2) compiled code should have bang p+2 and p+3. >>> >>> Ok. That would work indeed. >>> >>>>> >>>>> Had the compiler banged at P+3 (StackShadowPages+1) in 2), there would be no problem in that example. But then another example with my change and if the compiler bangs at sp+(StackShadowPages+1)*page. Let?s say StackShadowPages=2. >>>>> >>>>> 1) SP points in page P. We enter an interpreted frame. The frame is allocated. SP is still in P but right before the page boundary. The interpreter bangs P+1 and P+2. >>>>> 2) The interpreter pushes some arguments and we are now in P+1 and calls a compiled method. The compiler bangs P+4. P+3 was never touched. >>>>> >>>>> So that doesn?t work either. >>>>> >>>>> Wishing we had a whiteboard again? ;-) >>>> >>>> Yes and yes! >>>> >>>>> >>>>> Maybe the solution is for the compiler to bang at sp + StackShadowPages*page + (interpreter_frame_size % page) and the next interpreter_frame_size/page_size pages. That would mimic what the interpreter does and would work in both examples, above I think. interpreter_frame_size would have to not include what?s on the expression stack of the top frame to be as close as possible to the interpreter behavior. >>>> >>>> I don't see how you can determine "next interpreter_frame_size/page_size pages" >>>> >>>> As I said before if compiled code takes into account max stack size then first solution should work, I think. >>> >>> Let me try that. Thanks! >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>>> >>>>> Roland. >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 4/2/14 1:46 AM, Roland Westrelin wrote: >>>>>>>> The question is why you got EXCEPTION_ACCESS_VIOLATION for normal stack bang? May be it is 8026775 again when one page is skipped during banging. Windows requires sequential pages touche. >>>>>>> >>>>>>> I wasn?t aware of this requirement on windows. Thanks, Vladimir. >>>>>>> The interpreter bangs up to and including sp + StackShadowPages while the compiled code, with this change, bangs at sp + StackShadowPages + 1. So a page can be skipped and the requirement that all pages be touched sequentially cannot be guaranteed. So we either have to go back to banging at sp + StackShadowPages for the compiled code or enable the code that I pointed to in the signal on 32 bit. What do you think? >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 4/1/14 8:00 AM, Roland Westrelin wrote: >>>>>>>>> I tried to push that change and couldn?t because of a crash on windows 32 bit. The VM crashes at a stack banging instruction in compiled code but the sp looks to be perfectly valid (not in the yellow zone or red zone, within the stack bounds). I noticed this code in the windows signal handler: >>>>>>>>> >>>>>>>>> #ifdef _WIN64 >>>>>>>>> // >>>>>>>>> // If it's a legal stack address map the entire region in >>>>>>>>> // >>>>>>>>> PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; >>>>>>>>> address addr = (address) exceptionRecord->ExceptionInformation[1]; >>>>>>>>> if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base() ) { >>>>>>>>> addr = (address)((uintptr_t)addr & >>>>>>>>> (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); >>>>>>>>> os::commit_memory((char *)addr, thread->stack_base() - addr, >>>>>>>>> !ExecMem); >>>>>>>>> return EXCEPTION_CONTINUE_EXECUTION; >>>>>>>>> } >>>>>>>>> else >>>>>>>>> #endif >>>>>>>>> >>>>>>>>> If I enable it on 32 bit, the jprt tests pass. Does anybody know why this is needed? Why this is WIN64 only? >>>>>>>>> >>>>>>>>> Roland. >> > From volker.simonis at gmail.com Tue Apr 15 08:50:34 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 15 Apr 2014 10:50:34 +0200 Subject: Improve timezone mapping for AIX platform In-Reply-To: References: <53329D98.6040002@oracle.com> <534B7A25.7070800@oracle.com> Message-ID: You can push it to jdk9-dev directly. No other reviewer is required. Regards, Volker On Tue, Apr 15, 2014 at 9:48 AM, Jonathan Lu wrote: > Hi Masayoshi, Volker, > > Thanks a lot for reviewing ! > Is it OK for me to push the change into JDK9 directly ? or need another > reviewer's approval ? > > Many thanks > Jonathan > > > > On Mon, Apr 14, 2014 at 2:03 PM, Masayoshi Okutsu > wrote: >> >> Looks good to me. >> >> Thanks, >> Masayoshi >> >> >> On 4/11/2014 10:46 PM, Volker Simonis wrote: >> >> Hi Jonathan, >> >> thank you for fixing all the remaining issues. From my point of view this >> change looks good now. >> >> @Masayoshi: can I please get a final approval from you for pushing the >> change? I also want to downport this to 8u-dev but I don't think that's a >> big deal as this only touches AX code. >> >> Thank you and best regards, >> Volker >> >> On Thu, Apr 10, 2014 at 11:44 AM, Jonathan Lu >> wrote: >>> >>> Hi Volker, >>> >>> Thanks a lot for your comments, I've made another patch, >>> >>> http://cr.openjdk.java.net/~luchsh/JDK-8Masayoshi034220.v4/ >>> >>> >>> On Fri, Apr 4, 2014 at 9:22 PM, Volker Simonis >>> wrote: >>>> >>>> Hi Jonathan, >>>> >>>> sorry, but I found a few more issues: >>>> >>>> - please use strncpy instead of strcpy in TimeZone_md.c:798 otherwise >>>> somebody could easily crash the VM by specifying a TZ with more than >>>> 100 characters. >>> >>> >>> Right, I've fix it by using strncpy, and also updated another usage of >>> strcmp(). >>> >>> >>>> >>>> >>>> - you can delete the lines 871-872 because the variables are actually >>>> not used and you can also remove the handling for "timezone == 0" >>>> because that is actually done in getGMTOffsetID() anyway. >>> >>> >>> Nice catch, have deleted those in latest patch. >>> >>>> >>>> >>>> - could you please avoid the usage of strtok. It is not intended for >>>> usage in a multithreaded environment (see for example "man strtok" on >>>> AIX). strtok_r is probably overkill, but you could use for example >>>> strchr. >>> >>> >>> I've changed it to strtok_r in this patch, >>> although strtok was only used once here, it may still impact other >>> threads. >>> >>>> >>>> did you check the build on Windows? >>> >>> >>> Yes, both patches got built on Windows. >>> >>>> >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> >>>> On Fri, Apr 4, 2014 at 10:18 AM, Jonathan Lu >>>> wrote: >>>> > Hi Volker, Masayoshi, >>>> > >>>> > I made another patch which fixed the problems mentioned in last mail, >>>> > >>>> > http://cr.openjdk.java.net/~luchsh/JDK-8034220.v3/ >>>> > >>>> > Could you pls help to take a look? >>>> > >>>> > Many thanks >>>> > Jonathan >>>> > >>>> > >>>> > >>>> > On Thu, Apr 3, 2014 at 12:34 AM, Jonathan Lu >>>> > >>>> > wrote: >>>> >> >>>> >> Hi Volker, >>>> >> >>>> >> >>>> >> On 2014?04?02? 23:07, Volker Simonis wrote: >>>> >> >>>> >> Hi Jonathan, >>>> >> >>>> >> thanks for updating the change. Please find my comments inline: >>>> >> >>>> >> On Tue, Apr 1, 2014 at 4:52 PM, Jonathan Lu >>>> >> >>>> >> wrote: >>>> >> >>>> >> Hi Volker, Masayoshi, >>>> >> >>>> >> Thanks a lot for your review, here's the updated patch, could you pls >>>> >> take >>>> >> a >>>> >> look? >>>> >> >>>> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220.v2/ >>>> >> >>>> >> >>>> >> On Thu, Mar 27, 2014 at 1:48 AM, Volker Simonis >>>> >> >>>> >> wrote: >>>> >> >>>> >> Hi Jonathan, >>>> >> >>>> >> thanks for doing this change. Please find some comments below: >>>> >> >>>> >> 1. please update the copyright year to 2014 in every file you touch >>>> >> >>>> >> Updated in new patch. >>>> >> >>>> >> 2. in CopyFiles.gmk you can simplify the change by joining the >>>> >> windows >>>> >> and aix cases because on Windows OPENJDK_TARGET_OS is the same like >>>> >> OPENJDK_TARGET_OS_API_DIR. So you can write: >>>> >> >>>> >> ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), ) >>>> >> >>>> >> TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib >>>> >> >>>> >> $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings >>>> >> $(call install-file) >>>> >> >>>> >> COPY_FILES += $(LIBDIR)/tzmappings >>>> >> >>>> >> endif >>>> >> >>>> >> I've tried that approach before, but OPENJDK_TARGET_OS_API_DIR is >>>> >> 'solaris' >>>> >> as I observed on my AIX box, >>>> >> solaris/lib is not the directory where tzmappings was stored for AIX. >>>> >> So I'm keeping this change, please fix me if I was wrong about the >>>> >> config. >>>> >> >>>> >> Yes, but my point was to actually use OPENJDK_TARGET_OS for the >>>> >> construction of TZMAPPINGS_SRC as shown in the code snippet above. >>>> >> OPENJDK_TARGET_OS is "windows" on Windows platforms and "aix" on AIX >>>> >> and that should be just enough here. >>>> >> >>>> >> >>>> >> That's right, let me try that and also build/test on Windows >>>> >> platform. >>>> >> >>>> >> >>>> >> 3. regarding the changes proposed by Masayoshi: I agree that we >>>> >> should >>>> >> put the AIX timezone mapping code in its own function, but I don't >>>> >> think that getPlatformTimeZoneID() would be the right place. As far >>>> >> as >>>> >> I understand, getPlatformTimeZoneID() is used to get a platform time >>>> >> zone id if the environment variable "TZ" is not set. I don't know a >>>> >> way how this could be done on AIX (@Jonathan: maybe you know?). If >>>> >> there would be a way to get the time zone from some system files or >>>> >> so, then we should put this code into the AIX version of >>>> >> getPlatformTimeZoneID(). >>>> >> >>>> >> I guess we may try to use /etc/envrionment file, which is basic >>>> >> setting >>>> >> for >>>> >> all processes, >>>> >> see >>>> >> >>>> >> >>>> >> http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Fenvironment.htm >>>> >> The implementation of getPlatformTimeZoneID() has been updated. >>>> >> >>>> >> That's good! >>>> >> >>>> >> But the current AIX code contributed by Jonathan, actually uses the >>>> >> time zone id from the "TZ" environment variable and just maps it to a >>>> >> Java compatible time zone id. So I'd suggest to refactor this code >>>> >> into a function like for example "static const char* >>>> >> mapPlatformToJavaTimzone(const char* tz)" and call that from >>>> >> findJavaTZ_md(). I think that would make the code easier to >>>> >> understand. >>>> >> >>>> >> Agree, and have split the code into a separate static method to do >>>> >> the >>>> >> mapping work. >>>> >> >>>> >> Good. But there's still one error in findJavaTZ_md(): >>>> >> >>>> >> 706 #ifdef _AIX >>>> >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, tz); >>>> >> 708 #endif >>>> >> >>>> >> This should read: >>>> >> >>>> >> 706 #ifdef _AIX >>>> >> 707 javatz = mapPlatformToJavaTimezone(java_home_dir, >>>> >> javatz); >>>> >> 708 #endif >>>> >> >>>> >> because in line 703 you free 'tz' via its alias 'freetz' if 'tz' came >>>> >> from getPlatformTimeZoneID(). >>>> >> >>>> >> >>>> >> Right, but with the second approach, there may be a minor memory leak >>>> >> here, >>>> >> as javatz was not freed before being overwritten on AIX. will post >>>> >> another >>>> >> patch on this soon. >>>> >> >>>> >> >>>> >> With the above fixed I'll push this one we get one more review from a >>>> >> reviewer (I'm currently not an official reviewer). >>>> >> >>>> >> Regards, >>>> >> Volker >>>> >> >>>> >> >>>> >> @Masayoshi: what do you think, would you agree with such a solution. >>>> >> >>>> >> 4. I agree with Masayoshi that you should use the existing >>>> >> getGMTOffsetID() >>>> >> >>>> >> Updated in new patch to eliminate duplication. >>>> >> >>>> >> 5. Please notice that your change breaks all Unix builds except AIX >>>> >> because of: >>>> >> >>>> >> 759 } >>>> >> 760 tzerr: >>>> >> 761 if (javatz == NULL) { >>>> >> 762 time_t offset; >>>> >> ... >>>> >> 782 } >>>> >> 783 #endif >>>> >> >>>> >> I think that should read: >>>> >> >>>> >> 759 >>>> >> 760 tzerr: >>>> >> 761 if (javatz == NULL) { >>>> >> 762 time_t offset; >>>> >> ... >>>> >> 782 } >>>> >> 783 #endif >>>> >> 784 } >>>> >> >>>> >> Refactoring the code in an extra function will make that error more >>>> >> evident anyway. >>>> >> >>>> >> But please always build at least on one different platform (i.e. >>>> >> Linux) to prevent such errors in the future. >>>> >> >>>> >> My fault, sorry for the failure, should take no chance after any >>>> >> manual >>>> >> alteration. >>>> >> >>>> >> Regards, >>>> >> Volker >>>> >> >>>> >> >>>> >> On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu >>>> >> wrote: >>>> >> >>>> >> Hi Jonathan, >>>> >> >>>> >> The AIX specific code looks OK to me. But I'd suggest the code be >>>> >> moved >>>> >> to >>>> >> getPlatformTimeZoneID() for AIX, which just returns NULL currently. >>>> >> Also >>>> >> there's a function for producing a fallback ID in "GMT?hh:mm", >>>> >> getGMTOffsetID() which can be called in tzerr. >>>> >> >>>> >> Thanks, >>>> >> Masayoshi >>>> >> >>>> >> >>>> >> On 3/26/2014 3:47 PM, Jonathan Lu wrote: >>>> >> >>>> >> Hi ppc-aix-port-dev, core-libs-dev, >>>> >> >>>> >> Here's a patch for JDK-8034220, >>>> >> >>>> >> http://cr.openjdk.java.net/~luchsh/JDK-8034220/ >>>> >> >>>> >> It is trying to add the a more complete timezone mapping mechanism >>>> >> for >>>> >> AIX >>>> >> platform. >>>> >> the changes are primarily based on IBM's commercial JDK code, which >>>> >> includes: >>>> >> >>>> >> - A new timezone mapping file added under directory jdk/src/aix/lib/ >>>> >> - Code to parse above config file, changed file is >>>> >> src/solaris/native/java/util/TimeZone_md.c >>>> >> - And also makefile change in make/CopyFiles.gmk to copy the config >>>> >> file >>>> >> >>>> >> Could you pls help to review and give comments ? >>>> >> >>>> >> Cheers >>>> >> - Jonathan >>>> >> >>>> >> Many thanks >>>> >> Jonathan >>>> >> >>>> >> Regards >>>> >> Jonathan >>>> > >>>> > >>> >>> >>> Regards >>> Jonathan >> >> >> > From asmundak at google.com Wed Apr 16 03:02:59 2014 From: asmundak at google.com (Alexander Smundak) Date: Tue, 15 Apr 2014 20:02:59 -0700 Subject: [7u] RFR(M): 8036767 : PPC64: Support for little endian execution model In-Reply-To: References: Message-ID: Sorry about that. The change in Defs-linux.gmk had to be bracketed by ppc64. The new webrev for the jdk/ repository is in http://cr.openjdk.java.net/~asmundak/8036767.7u/jdk/webrev.01 I have built it for PowerPC64 little- and big-endian and for Linux/amd64. I have never built OpenJDK for Windows and it would require some amount of paperwork for me to do this at work. I can try it on my home computer if you insist. On Tue, Apr 15, 2014 at 1:48 AM, Volker Simonis wrote: > Hi Sasha, > > with your changes the build fails in jdk on non-ppc Linux because > OPENJDK_TARGET_CPU_ENDIAN is not defined. > > Could you please also test your changes on other platforms than ppc > (i.e. at least Linux/amd64 and Windows) in the future. > > Thank you and best regards, > Volker > > On Fri, Apr 11, 2014 at 5:54 AM, Alexander Smundak wrote: >> This set of patches is the backport of the corresponding changes for >> the OpenJDK9 >> (see http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/09edc8e9fa4d). >> Additional changes were required in the build machinery for corba/, >> jdk/ and langtools/ repositories. >> >> http://cr.openjdk.java.net/~asmundak/8036767.7u/corba/webrev.00 >> http://cr.openjdk.java.net/~asmundak/8036767.7u/hotspot/webrev.00 >> http://cr.openjdk.java.net/~asmundak/8036767.7u/jdk/webrev.00 >> http://cr.openjdk.java.net/~asmundak/8036767.7u/langtools/webrev.00 >> >> Sasha From volker.simonis at gmail.com Wed Apr 16 08:22:45 2014 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Wed, 16 Apr 2014 08:22:45 +0000 Subject: hg: ppc-aix-port/jdk7u/jdk: 8036767: PPC64: Support for little endian execution model Message-ID: <201404160822.s3G8MpMC009069@aojmv0008> Changeset: 6aaf00000bd5 Author: asmundak Date: 2014-04-16 01:58 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/jdk/rev/6aaf00000bd5 8036767: PPC64: Support for little endian execution model Reviewed-by: simonis ! make/common/Defs-linux.gmk ! make/common/shared/Platform.gmk ! make/jdk_generic_profile.sh From volker.simonis at gmail.com Wed Apr 16 08:25:51 2014 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Wed, 16 Apr 2014 08:25:51 +0000 Subject: hg: ppc-aix-port/jdk7u/corba: 8036767: PPC64: Support for little endian execution model Message-ID: <201404160825.s3G8Pp1v009474@aojmv0008> Changeset: 089deee629ea Author: asmundak Date: 2014-04-11 03:12 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/rev/089deee629ea 8036767: PPC64: Support for little endian execution model Reviewed-by: simonis ! make/common/shared/Platform.gmk From volker.simonis at gmail.com Wed Apr 16 08:29:01 2014 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Wed, 16 Apr 2014 08:29:01 +0000 Subject: hg: ppc-aix-port/jdk7u/hotspot: 8036767: PPC64: Support for little endian execution model Message-ID: <201404160829.s3G8T2vF010015@aojmv0008> Changeset: 1336943134da Author: asmundak Date: 2014-04-11 03:12 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/1336943134da 8036767: PPC64: Support for little endian execution model Reviewed-by: simonis ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/ppc64.make ! src/cpu/ppc/vm/assembler_ppc.hpp ! src/cpu/ppc/vm/bytes_ppc.hpp ! src/os/linux/vm/os_linux.cpp + src/os_cpu/linux_ppc/vm/bytes_linux_ppc.inline.hpp From volker.simonis at gmail.com Wed Apr 16 08:30:54 2014 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Wed, 16 Apr 2014 08:30:54 +0000 Subject: hg: ppc-aix-port/jdk7u/langtools: 8036767: PPC64: Support for little endian execution model Message-ID: <201404160830.s3G8Utvb010205@aojmv0008> Changeset: 1ea9bfffd3d0 Author: asmundak Date: 2014-04-11 03:13 +0000 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/langtools/rev/1ea9bfffd3d0 8036767: PPC64: Support for little endian execution model Reviewed-by: simonis ! test/Makefile From volker.simonis at gmail.com Wed Apr 16 09:06:22 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 16 Apr 2014 11:06:22 +0200 Subject: [7u] RFR(M): 8036767 : PPC64: Support for little endian execution model In-Reply-To: References: Message-ID: Hi Sasha, thanks for updating the change. I have just pushed all four patches to the corresponding repositories. Regards, Volker On Wed, Apr 16, 2014 at 5:02 AM, Alexander Smundak wrote: > Sorry about that. The change in Defs-linux.gmk had to be bracketed by > ppc64. > The new webrev for the jdk/ repository is in > http://cr.openjdk.java.net/~asmundak/8036767.7u/jdk/webrev.01 > > I have built it for PowerPC64 little- and big-endian and for Linux/amd64. > I have never built OpenJDK for Windows and it would require some > amount of paperwork for me to do this at work. I can try it on my home > computer if you insist. > > On Tue, Apr 15, 2014 at 1:48 AM, Volker Simonis > wrote: > > Hi Sasha, > > > > with your changes the build fails in jdk on non-ppc Linux because > > OPENJDK_TARGET_CPU_ENDIAN is not defined. > > > > Could you please also test your changes on other platforms than ppc > > (i.e. at least Linux/amd64 and Windows) in the future. > > > > Thank you and best regards, > > Volker > > > > On Fri, Apr 11, 2014 at 5:54 AM, Alexander Smundak > wrote: > >> This set of patches is the backport of the corresponding changes for > >> the OpenJDK9 > >> (see http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/09edc8e9fa4d). > >> Additional changes were required in the build machinery for corba/, > >> jdk/ and langtools/ repositories. > >> > >> http://cr.openjdk.java.net/~asmundak/8036767.7u/corba/webrev.00 > >> http://cr.openjdk.java.net/~asmundak/8036767.7u/hotspot/webrev.00 > >> http://cr.openjdk.java.net/~asmundak/8036767.7u/jdk/webrev.00 > >> http://cr.openjdk.java.net/~asmundak/8036767.7u/langtools/webrev.00 > >> > >> Sasha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ChrisPhi at LGonQn.Org Tue Apr 29 13:50:11 2014 From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O) Date: Tue, 29 Apr 2014 09:50:11 -0400 Subject: PPC64: Support for little endian execution model now functional [Resend to list] ? In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> <5333DBCB.6050200@oracle.com> Message-ID: <535FAE13.5010901@LGonQn.Org> Hi Is the ppc-aix-port now considered working for ppc64le ? (In particular jdk8u20 and jdk7 from the port repo.) Or are their further changes coming ? Thanks! Chris From asmundak at google.com Tue Apr 29 16:51:55 2014 From: asmundak at google.com (Alexander Smundak) Date: Tue, 29 Apr 2014 09:51:55 -0700 Subject: PPC64: Support for little endian execution model now functional [Resend to list] ? In-Reply-To: <535FAE13.5010901@LGonQn.Org> References: <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> <5333DBCB.6050200@oracle.com> <535FAE13.5010901@LGonQn.Org> Message-ID: It is working, that is, it builds and is capable of compiling itself. However, it is not on par with big endian PPC64 as template interpreter is not supported yet. On Tue, Apr 29, 2014 at 6:50 AM, Chris Phillips @ T O wrote: > Hi > > Is the ppc-aix-port now considered working for ppc64le ? > (In particular jdk8u20 and jdk7 from the port repo.) > Or are their further changes coming ? > > Thanks! > Chris > From asmundak at google.com Tue Apr 29 18:12:15 2014 From: asmundak at google.com (Alexander Smundak) Date: Tue, 29 Apr 2014 11:12:15 -0700 Subject: PPC64: Support for little endian execution model now functional [Resend to list] ? In-Reply-To: <1398792892.3914.119.camel@ocdc.br.ibm.com> References: <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> <5333DBCB.6050200@oracle.com> <535FAE13.5010901@LGonQn.Org> <1398792892.3914.119.camel@ocdc.br.ibm.com> Message-ID: You are probably using the default JDK installed in /usr/lib/jvm to build this one. The easiest solution is to go to that directory and make a symlink called ppc64 pointing to ppc64le in jre/lib directory. The longer explanation is that the default JDK treats little endian PPC64 as a different architecture, and thus expectd libjvm.so is in the ppc64le directory. My originial proposal to do the same was rejected, and now little endian is treated as variant of the ppc64. This did not cause any problem for JDK9 or JDK8, but due to the gamma build trying to use freshly built JVM with bootstrap JDK this causes a problem in JDK7. On Tue, Apr 29, 2014 at 10:34 AM, Tiago Sturmer Daitx wrote: > On Tue, 2014-04-29 at 09:51 -0700, Alexander Smundak wrote: >> It is working, that is, it builds and is capable of compiling itself. >> However, it is not on par with big endian PPC64 as template >> interpreter is not supported yet. >> > > Alexander, > > Right now I'm facing some hotspot problems related to gamma and > test_gama that I'm trying to track down and fix. > > The hotspot/outputdir/linux_ppc64_compiler2/product/test_gamma script is > using ppc64 paths instead of ppc64le: > > LD_LIBRARY_PATH=.:${JAVA_HOME}/jre/lib/ppc64/native_threads: > ${JAVA_HOME}/jre/lib/ppc64: > > and even after fixing LD_LIBRARY_PATH > the /root/jdk7u/build/linux-ppc64/hotspot/outputdir/linux_ppc64_compiler2/product/gamma binary still uses ppc64: > > access("/usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/libjava.so", F_OK) = > -1 ENOENT (No such file or directory) > access("/usr/lib/jvm/java-7-openjdk-ppc64el/lib/ppc64/libjava.so", F_OK) > = -1 ENOENT (No such file or directory) > access("/usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/ppc64/libjava.so", > F_OK) = -1 ENOENT (No such file or directory) > > > Am I missing any additional flags when building on a PPC64LE system? > > Regards, > Tiago > > -- > Tiago Sturmer Daitx > Linux Technology Center [LTC|IBM] > tdaitx at linux.vnet.ibm.com >