Re: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code [v4]

On Wed, 28 Oct 2020 13:49:53 GMT, Severin Gehwolf wrote: >> Test only change. With >> [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has >> been added on the hotspot side, but nothing for the Java Metrics code. Same >> for

Re: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6]

On Thu, 8 Oct 2020 13:38:59 GMT, Severin Gehwolf wrote: >> An issue similar to >> [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been >> discovered. On the >> affected system, `/proc/self/mountinfo` contains a line such as this one: >> >> 35 26 0:26 /

Re: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v5]

On Thu, 8 Oct 2020 13:36:20 GMT, Severin Gehwolf wrote: >> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java >> line 185: >> >>> 183: } else { >>> 184:// fallback to old, pre JDK-8245543, behaviour >>> 185:return

Re: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v5]

On Thu, 8 Oct 2020 12:51:54 GMT, Severin Gehwolf wrote: >> An issue similar to >> [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been >> discovered. On the >> affected system, `/proc/self/mountinfo` contains a line such as this one: >> >> 35 26 0:26 /

Re: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3]

On Wed, 7 Oct 2020 08:06:58 GMT, Severin Gehwolf wrote: >> OK. I'll probably fold JDK-8254001 into this one then. > > @bobvandette Done in the latest version. Thoughts? I'm a little uncomfortable making such a dramatic change just to fix this small isolated problem. I think about all the

Re: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3]

On Mon, 5 Oct 2020 10:16:49 GMT, Severin Gehwolf wrote: >> An issue similar to >> [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been >> discovered. On the >> affected system, `/proc/self/mountinfo` contains a line such as this one: >> >> 35 26 0:26 /

Re: RFR: 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities

On Tue, 29 Sep 2020 19:57:14 GMT, Coleen Phillimore wrote: >> Please review this small change to remove "--memory 200m" option from >> TestUseContainerSupport.java. This can cause >> test failures on systems where swap accounting is disabled. > > Marked as reviewed by coleenp (Reviewer).

Re: RFR: 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities

On Tue, 22 Sep 2020 15:52:43 GMT, Harold Seigel wrote: > Please review this small change to remove "--memory 200m" option from > TestUseContainerSupport.java. This can cause > test failures on systems where swap accounting is disabled. Marked as reviewed by bobv (Committer). -

Re: RFR: 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o…

On Tue, 22 Sep 2020 15:52:43 GMT, Harold Seigel wrote: > Please review this small change to remove "--memory 200m" option from > TestUseContainerSupport.java. This can cause > test failures on systems where swap accounting is disabled. Marked as reviewed by bobv (Committer). -

Re: RFR(s): 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics

Looks good to me. Bob. > On Jul 28, 2020, at 10:01 AM, Severin Gehwolf wrote: > > Hi David, > > Thanks for the review. > > On Tue, 2020-07-28 at 23:49 +1000, David Holmes wrote: >> Hi Severin, >> >> On 28/07/2020 11:23 pm, Severin Gehwolf wrote: >>> Hi David, >>> >>> On Tue, 2020-07-28 at

Re: No way to disable Java Container Metrics

> On Jul 27, 2020, at 11:32 AM, Severin Gehwolf wrote: > > Hi Bob, > > On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote: >> I’ve been monitoring the discussion on your jdk8u alias and I can’t help >> wondering if >> my original decision to prov

Re: No way to disable Java Container Metrics

I’ve been monitoring the discussion on your jdk8u alias and I can’t help wondering if my original decision to provide two different implementations of this container detection logic was the best way to go. I didn’t want to have an all Java implementation since the VM needs to initialize it’s

Re: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy

> On Feb 18, 2020, at 2:00 PM, Mandy Chung wrote: > > > > On 2/18/20 4:50 AM, Severin Gehwolf wrote: >> Hi Mandy, >> >> Thanks again for the review! >> >> Updated webrev: >> incremental (only review changes): >>

Re: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy

/build/jtreg/JTwork Bob. > On Feb 12, 2020, at 10:13 AM, Bob Vandette wrote: > > >> On Feb 12, 2020, at 6:22 AM, Severin Gehwolf wrote: >> >> Hi Bob, >> >> On Tue, 2020-02-11 at 16:59 -0500, Bob Vandette wrote: >>> I applied your patch to

Re: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy

> On Feb 12, 2020, at 6:22 AM, Severin Gehwolf wrote: > > Hi Bob, > > On Tue, 2020-02-11 at 16:59 -0500, Bob Vandette wrote: >> I applied your patch to the latest JDK 15 sources and ran the container >> tests on Oracle Linux 8.1 with podman/cgroupv2 enabled.

Re: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy

I applied your patch to the latest JDK 15 sources and ran the container tests on Oracle Linux 8.1 with podman/cgroupv2 enabled. There were some issues. I’m not sure if its my setup or not. I also ran the same build on Ubuntu with docker/cgroupv1. I didn't see any failures on the cgroupv1

Re: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy

> On Jan 22, 2020, at 11:06 AM, Mandy Chung wrote: > > > > On 1/22/20 1:53 AM, Severin Gehwolf wrote: >> Hi Mandy, >> >> Thanks again for the review! I'll be sure to fix things. Some of the >> issues you've pointed out probably pre-existed in old code. Some became >> more complicated since

Re: 8226575: OperatingSystemMXBean should be made container aware

>> from stdout/stderr >> >> at >> jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:306) >> at >> TestMemoryAwareness.testOperatingSystemMXBeanAwareness(TestMemoryAwareness.java:151) >> at TestMemoryAwareness.main(TestMemoryAwareness

Re: RFR: 8226575: OperatingSystemMXBean should be made container aware

MRunnable.run(MainActionHelper.java:298) > at java.base/java.lang.Thread.run(Thread.java:832) > > Testing: Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker > tests passed. Tier4-tier6 tests are still running. > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8226575/webrev.

Re: RFR: 8226575: OperatingSystemMXBean should be made container aware

tion and then put AccessController.doPrivileged >> call inside new try/catch Block to catch PrivilegedExceptionAction. The >> former approach looked more preferable. >> Testing: Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker >> tests passed. Tier4-tier6 te

Re: RFR: 8226575: OperatingSystemMXBean should be made container aware

In http://cr.openjdk.java.net/~dtitov/8226575/webrev.03/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java.sdiff.html Shouldn’t you keep the IOException catch clauses in case the file is not found? > On Dec 5, 2019, at 2:31 PM, Daniil Titov wrote: > > Hi Mandy and Bob,

Re: jmx-dev 8226575: OperatingSystemMXBean should be made container aware

> On Dec 4, 2019, at 8:32 AM, Bob Vandette wrote: > > >> On Dec 3, 2019, at 9:00 PM, Daniil Titov wrote: >> >> Hi Bob, >> >>>> It’s too bad getCpuLoad can’t detect that the cpuset is identical to the >>>> hosts in order to allow you

Re: 8226575: OperatingSystemMXBean should be made container aware

rMetrics.getEffectiveCpuSetCpus(). The length of the array returned is the number of host cpus. Maybe Severin can confirm if this true in cgroupv2 as well. Bob. > > Thank you, > Daniil > > On 12/3/19, 1:30 PM, "Bob Vandette" wrote: > >Daniil, > &

Re: RFR: 8226575: OperatingSystemMXBean should be made container aware

Daniil, Looks good to me. If there are any management jtreg tests, I’d run these since your changes to OperatingSystemMXBean will alter the behavior of these methods even for Linux hosts since cgroups is typically enabled causing the container detection to report containerized. It’s too bad

Re: RFR(S): 8228960: [TESTBUG] containers/docker/TestJcmdWithSideCar.java: jcmd reports main class as 'Unknown'

you for the suggestion. I will update the code accordingly. >>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~mseledtsov/8228960.02/ >>> >>> Otherwise looks okay. Hopefully those other test cases will be enabled in &g

Re: RFR(S): 8228960: [TESTBUG] containers/docker/TestJcmdWithSideCar.java: jcmd reports main class as 'Unknown'

> On Aug 13, 2019, at 3:28 PM, mikhailo.seledt...@oracle.com wrote: > > > On 8/13/19 12:06 PM, Bob Vandette wrote: >> >>> On Aug 13, 2019, at 2:57 PM, mikhailo.seledt...@oracle.com wrote: >>> >>> Hi Bob, >>> >>> The workd

Re: RFR(S): 8228960: [TESTBUG] containers/docker/TestJcmdWithSideCar.java: jcmd reports main class as 'Unknown'

y this, and let you know how it works. > > > Thank you, > > Misha > > On 8/13/19 6:34 AM, Bob Vandette wrote: >> Sorry, I just looked at the webrev and you are trying the approach I >> suggested. I thought you >> were trying to use file change not

Re: RFR(S): 8228960: [TESTBUG] containers/docker/TestJcmdWithSideCar.java: jcmd reports main class as 'Unknown'

Sorry, I just looked at the webrev and you are trying the approach I suggested. I thought you were trying to use file change notification. Where does the workdir get created? Does it have 777 permissions? Bob. > On Aug 13, 2019, at 9:29 AM, Bob Vandette wrote: > > What if you

Re: RFR(S): 8228960: [TESTBUG] containers/docker/TestJcmdWithSideCar.java: jcmd reports main class as 'Unknown'

>> Misha >> >> On 8/7/19 5:11 PM, David Holmes wrote: >>> On 8/08/2019 9:04 am, Mikhailo Seledtsov wrote: >>>> Hi Severin, Bob, >>>> >>>>Thank you for reviewing the code. >>>> >>>> On 8/7/19, 11:38 AM, Bob Vandette

Re: OperatingSystemMXBean unaware of container memory limits

> On Jul 11, 2019, at 1:18 PM, Andrew Azores wrote: > > Hi Bob (and all), > > On Fri, 2019-06-21 at 08:50 -0400, Bob Vandette wrote: >>> >> Fixing the existing OS Mbean is pretty straight forward. Just have >> each method call the new Metrics API, check f

Re: OperatingSystemMXBean unaware of container memory limits

Here you go. https://bugs.openjdk.java.net/browse/JDK-8226575 <https://bugs.openjdk.java.net/browse/JDK-8226575> Thanks, Bob. > On Jun 21, 2019, at 9:08 AM, Severin Gehwolf wrote: > > Hi Bob, > > On Fri, 2019-06-21 at 08:56 -0400, Bob Vandette wrote: >>> On Jun

Re: OperatingSystemMXBean unaware of container memory limits

> On Jun 21, 2019, at 4:22 AM, Severin Gehwolf wrote: > > Hi Bob, > > On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: >> Hi Andrew, >> >> I am aware of the limitations of the OperatingSystemMXBean and was >> hoping to address these limitation

Re: OperatingSystemMXBean unaware of container memory limits

API. jdk/open/src/java.base/share/classes/jdk/internal/platform/Metrics.java You’d need to ensure proper javadocs are available and jtreg tests would need to be written to validate the new APIs. Bob. > > Cheers, > Mario > > On Fri 21. Jun 2019 at 10:53, Severin Gehwolf wrote:

Re: OperatingSystemMXBean unaware of container memory limits

k up, even for students >> wanting to write a thesis, as it seems time is a limiting factor here for >> you to work on that? >> >> Cheers, >> Mario >> >> On Fri 21. Jun 2019 at 10:53, Severin Gehwolf > <mailto:sgehw...@redhat.com>> wrote

Re: OperatingSystemMXBean unaware of container memory limits

Hi Andrew, I am aware of the limitations of the OperatingSystemMXBean and was hoping to address these limitations during the implementation of https://bugs.openjdk.java.net/browse/JDK-8199944 . It would be helpful if you feel this is important

Re: RFR: 8217338: [Containers] Improve systemd slice memory limit support

Sorry for the delay. The update looks good. Bob. > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: > > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: >> Could you maybe combine subsystem_file_contents with >> subsystem_file_line_contents >> by ad

Re: RFR: 8217338: [Containers] Improve systemd slice memory limit support

Is there ever a situation where the memory.limit_in_bytes could be unlimited but the hierarchical_memory_limit is not? Could you maybe combine subsystem_file_contents with subsystem_file_line_contents by adding an additional argument? BTW: I found another problem with the mountinfo/cgroup

RFR: 8220674: [TESTBUG] MetricsMemoryTester failcount test in docker container only works with debug JVMs

Please review this fix for a container test that fails on some Linux distributions. The test fails to see the Memory Fail count metric value increase. This is caused by the fact that we are allowing ergonomics to select the amount of Heap size. This size varies depending on the amount of

Re: RFR: 8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp

The change looks good. Thanks for fixing this. I’d send this to core-libs (cc’d). Bob. > On Mar 14, 2019, at 12:51 PM, Severin Gehwolf wrote: > > Hi, > > I'm not sure what the right list for Metrics.java[1] is. Assuming it's > serviceability-dev: > > Please review this one-liner for for

Re: [PATCH] Windows 32-bit DLL name decoration

Hotspot has had support for decorated and non-decorated names for the JNI_OnLoad functions. Perhaps you should just follow the same procedure for the debug library. #define JNI_ONLOAD_SYMBOLS {"_JNI_OnLoad@8", "JNI_OnLoad"} #define JNI_ONUNLOAD_SYMBOLS {"_JNI_OnUnload@8", "JNI_OnUnload"}

Re: RFR: 8206456 - [TESTBUG] docker jtreg tests fail on systems without cpuset.effective_cpus / cpuset.effective_mem

> On Jul 17, 2018, at 8:07 PM, mandy chung wrote: > > > > On 7/17/18 7:00 AM, Bob Vandette wrote: >> Please review this fix which eliminates some docker/cgroup test failures >> when running on older >> Linux kernels with missing cgroup metric files. >>

RFR: 8206456 - [TESTBUG] docker jtreg tests fail on systems without cpuset.effective_cpus / cpuset.effective_mem

Please review this fix which eliminates some docker/cgroup test failures when running on older Linux kernels with missing cgroup metric files. BUGS: https://bugs.openjdk.java.net/browse/JDK-8206456 WEBREV: http://cr.openjdk.java.net/~bobv/8206456/webrev/ This fix has been verified by the

Re: RFR: 8205928 - [TESTBUG]: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails depending on kernel config

ards, Thomas > > On Tue, Jul 3, 2018 at 3:13 PM, Bob Vandette wrote: >> Please review this small fix to correct a test failure when the Linux system >> kernel is >> not configured with the CONFIG_MEMCG_KMEM option. >> >> The Container Metric tests are depend

RFR: 8205928 - [TESTBUG]: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails depending on kernel config

Please review this small fix to correct a test failure when the Linux system kernel is not configured with the CONFIG_MEMCG_KMEM option. The Container Metric tests are dependent on docker which allow us to assume a certain minimum Linux kernel configuration level. However, the kernel memory

Re: RFR(xxs): 8206243: java -XshowSettings fails if memory.limit_in_bytes overflows LONG.max

Looks ok. Bob. > On Jul 3, 2018, at 5:15 AM, Thomas Stüfe wrote: > > Thank you David! > > I changed the webrev in place. > > Thanks, Thomas > > On Tue, Jul 3, 2018 at 10:37 AM, David Holmes wrote: >> Hi Thomas, >> >> This seems okay. >> >> Minor nit: >> >> if(bigInt >> >> Please add a

Re: Ping!! Re: RFR: 8203357 Container Metrics

> On Jun 12, 2018, at 1:43 AM, David Holmes wrote: > >> On 12/06/2018 3:31 PM, mandy chung wrote: >> On 6/11/18 10:12 PM, David Holmes wrote: >>> >>> For the Java code ... methods that return arrays should return >>> zero-length arrays when something is not available rather than

Re: Ping!! Re: RFR: 8203357 Container Metrics

> On Jun 12, 2018, at 1:12 AM, David Holmes wrote: > > On 12/06/2018 9:30 AM, Bob Vandette wrote: >>> On Jun 11, 2018, at 5:21 PM, David Holmes wrote: >>> >>> On 12/06/2018 12:12 AM, Bob Vandette wrote: >>>>> On Jun 11, 2018, at 4:32 AM

Re: Ping!! Re: RFR: 8203357 Container Metrics

> On Jun 11, 2018, at 5:21 PM, David Holmes wrote: > > On 12/06/2018 12:12 AM, Bob Vandette wrote: >>> On Jun 11, 2018, at 4:32 AM, David Holmes >> <mailto:david.hol...@oracle.com>> wrote: >>> >>> Sorry Bob I haven't had a chance to look at

Re: Ping!! Re: RFR: 8203357 Container Metrics

> On Jun 11, 2018, at 4:07 AM, Robbin Ehn wrote: > > Hi Bob, > > On 06/07/2018 07:43 PM, Bob Vandette wrote: >> Can I get one more reviewer for this RFE so I can integrate it? >>> http://cr.openjdk.java.net/~bobv/8203357/webrev.01 > > Seems okay. >

Re: Ping!! Re: RFR: 8203357 Container Metrics

at it’s process and cgroup (Isolation group) specific and not the generic os timeslice. Isn’t this sufficient? Thanks, Bob. > > David > > On 8/06/2018 3:43 AM, Bob Vandette wrote: >> Can I get one more reviewer for this RFE so I can integrate it? >>> http://cr.openjdk.java.net/~b

Re: Ping!! Re: RFR: 8203357 Container Metrics

he tests. In general they look good. I am a bit concerned >> about the use of ERROR_MARGIN in one of the tests. We need to make sure that >> the tests are stable, and do not produce intermittent failures. >> >> >> Thank you, >> Misha >> >>

Ping!! Re: RFR: 8203357 Container Metrics

and line change and it’s now approved and closed. Thanks, Bob. > On May 30, 2018, at 3:45 PM, Bob Vandette wrote: > > Please review the following RFE which adds an internal API, along with jtreg > tests that provide > access to Docker container configuration data and met

Re: RFR: 8203357 Container Metrics

> On May 31, 2018, at 11:36 PM, mandy chung wrote: > > Hi Bob, > > On 5/30/18 12:45 PM, Bob Vandette wrote:> >> RFE: Container Metrics >> https://bugs.openjdk.java.net/browse/JDK-8203357 >> WEBREV: >> http://cr.openjdk.java.net/~bobv/8203357/webrev.

RFR: 8203357 Container Metrics

Please review the following RFE which adds an internal API, along with jtreg tests that provide access to Docker container configuration data and metrics. In addition to the API which we hope to take advantage of in the future with Java Flight Recorder and a JMX Mbean, I’ve added an

Re: RFR: 81820709 - Container Awareness JEP

> On May 24, 2018, at 2:42 PM, mandy chung <mandy.ch...@oracle.com> wrote: > > > > On 5/23/18 7:39 AM, Bob Vandette wrote: >>> Should this be an instance method? like >>> cpuacct.getLongValue("cpuacct.usage”); > > >> I did it t

Re: RFR: 81820709 - Container Awareness JEP

below ... > On Apr 17, 2018, at 10:25 PM, mandy chung <mandy.ch...@oracle.com> wrote: > > > > On 4/3/18 10:09 PM, Bob Vandette wrote: >> WEBREV: >> >> http://cr.openjdk.java.net/~bobv/8182070/v01/webrev >> <http://cr.openjdk.java.net/~bobv/818207

RFR: 81820709 - Container Awareness JEP

ns Completed: 42 BLKIO: Bytes Transferred from disk: 4923392 Bob Vandette

RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers

Please review this change that resolves the detection of Java processes that are running in cgroup based containers. This latest (and hopefully final) update of this fix addresses comments from David Holmes and Mandy Chung. Bug: https://bugs.openjdk.java.net/browse/JDK-8193710 Webrev:

Re: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers

for all platforms except > Linux. One option is to have a shared implementation class and instantiate > an alternate implementation class, if present, using Class::forName. > Another minor point is that the new getVMTemporaryDirectories method can > return a List rather than an array. >

RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers

Here’s an updated webrev addressing the comments from David Holmes. 1. Moved new cgroup specific support from unix -> Linux and put stubs in all other OS's 2. Reduced the size of the stack arrays in perfMemory_linux.cpp There are still two outstanding issues: [serviceability] : Can we and

Re: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers

va processes is at least not in a performance critical area. > > On 12/01/2018 4:41 AM, Bob Vandette wrote: >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8193710 >> Webrev: >> http://cr.openjdk.java.net/~bobv/8193710/webrev.00/ >> Summary: >> This c

RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers

Bug: https://bugs.openjdk.java.net/browse/JDK-8193710 Webrev: http://cr.openjdk.java.net/~bobv/8193710/webrev.00/ Summary: This changeset enables the ability to use jcmd and jps running on a Host to list the java processes that are running in docker (cgroup based) containers. I’ve tested

Re: RFR - Changes to address CCC 8014135: Support for statically linked agents

On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: On 8/2/2013 9:12 PM, serguei.spit...@oracle.com wrote: Hi Bill, A couple of more questions. webrev.01/jvmti.html An agent L whose image has been combined with the VM *is defined* as /statically linked/ if and only if the agent

Re: RFR - Changes to address CCC 8014135: Support for statically linked agents

Serguei, Are you ok with the webrev at this point or are you waiting for any changes from Bill? I've asked Coleen to review the code since she's an official Reviewer but she'd like to make sure the serviceability team is ok with the changes. Bob. On Aug 3, 2013, at 12:34 AM,

Re: RFR - Changes to address CCC 8014135: Support for statically linked agents

Thanks for the suggestion Jeremy but the JVMTI agent change is being implemented as part of the original JNI static library implementation where we explicitly prohibited dynamic libraries to be loaded if a static library of the same name is baked into the launcher. If a library L is

Re: review request for JDK-8013461 There is a symbol AsyncGetCallTrace in libjvm.symbols that does not exist in minimal/libjvm.a when DEBUG_LEVEL == release

Joe, I'm ok with this approach. Bob. On May 22, 2013, at 3:27 PM, Joseph Provino wrote: Is there a consensus what is in the webrev is okay? The change is to include forte.cpp in the minimal jvm but to conditionalize the code so that only AsyncGetCallTrace() is defined with the minimal

hg: jdk7/hotspot-rt/hotspot: 2 new changesets

Changeset: b92c45f2bc75 Author:bobv Date: 2011-02-02 11:35 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b92c45f2bc75 7016023: Enable building ARM and PPC from src/closed repository Reviewed-by: dholmes, bdelsart ! make/Makefile + make/closed.make !

hg: jdk7/hotspot-rt/hotspot: 2 new changesets

Changeset: 2f9d59b0fa5c Author:bobv Date: 2011-01-07 12:44 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2f9d59b0fa5c 7009268: guarantee(middle - slop start) failed: need enough space to divide up Summary: Codebuffer can overflow on test with large number of

hg: jdk7/hotspot-rt/hotspot: 7007769: VM crashes with SIGBUS writing PerfData if tmp space is full

Changeset: 02895c6a2f82 Author:bobv Date: 2010-12-20 14:30 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/02895c6a2f82 7007769: VM crashes with SIGBUS writing PerfData if tmp space is full Summary: Fill perfdata file with zeros to verify available disk space

hg: jdk7/hotspot-rt/hotspot: 7004217: Remove IA64 workaround re-introduced with CR6953477

Changeset: 6a2d73358ff7 Author:bobv Date: 2010-12-02 14:00 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6a2d73358ff7 7004217: Remove IA64 workaround re-introduced with CR6953477 Summary: gcc bug worksaround for IA64 no longer needed Reviewed-by: andrew !

hg: jdk7/hotspot-rt/hotspot: 2 new changesets

Changeset: 3dc12ef8735e Author:bobv Date: 2010-10-07 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3dc12ef8735e 6989297: Integrate additional portability improvements Reviewed-by: vladidan, dholmes ! src/cpu/sparc/vm/globals_sparc.hpp !

hg: jdk7/hotspot-rt/hotspot: 6953477: Increase portability and flexibility of building Hotspot

Changeset: 126ea7725993 Author:bobv Date: 2010-08-03 08:13 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/126ea7725993 6953477: Increase portability and flexibility of building Hotspot Summary: A collection of portability improvements including shared code