From Tim.Bell at Sun.COM  Thu May 10 17:55:35 2007
From: Tim.Bell at Sun.COM (Tim Bell)
Date: Thu, 10 May 2007 17:55:35 -0700
Subject: [PATCH] Set GNU stack marking for non-executable stack on Linux
Message-ID: <4643BF07.5000901@sun.com>

Forwarded message

Please update your address books.  Stop using hotspot-dev at openjdk.dev.java.net
                                                                  ^^^^
and use hotspot-dev at openjdk.java.net instead (note the missing .dev).


-------- Original Message --------
The attached patch adds the GNU stack markings so that the stack is not
marked as RWX (both writable and executable). This is actually a minor
issues as with an enforced PaX (NX), Java will still not work because
of the JIT compiler, but at least it will remove one issue present
after building OpenJDK.

I'm not sure how the released binaries don't have the stacks marked as
executable, I suppose something might be mangling them afterward, but
this should cover the issue from the start.
The optimal way to handle this would have been to have it conditional
to Linux and ELF target, but that would have required to have
pre-processed sources (.S, rather than .s), and the two source files
are only for Linux (and thus only for ELF) anyway.

It also requires GNU as, but I think that is true already.

--=
Diego "Flameeyes" Petten=C3=B2
http://farragut.flameeyes.is-a-geek.org/

--MP_m0vvBlEIdtBj7CmDh5DKDIs
Content-Type: text/x-patch; name=openjdk-execstac.patch
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=openjdk-execstac.patch

Index: openjdk/hotspot/src/os_cpu/linux_amd64/vm/linux_amd64.s
==========================
==========================
=================
--- openjdk.orig/hotspot/src/os_cpu/linux_amd64/vm/linux_amd64.s
+++ openjdk/hotspot/src/os_cpu/linux_amd64/vm/linux_amd64.s
@@ -401,3 +401,5 @@ acl_CopyLeft:
          addq     $4,%rdx
          jg       4b
          ret
+
+.section .note.GNU-stack,"",%progbits
Index: openjdk/hotspot/src/os_cpu/linux_i486/vm/linux_i486.s
==========================
==========================
=================
--- openjdk.orig/hotspot/src/os_cpu/linux_i486/vm/linux_i486.s
+++ openjdk/hotspot/src/os_cpu/linux_i486/vm/linux_i486.s
@@ -651,3 +651,4 @@ _Atomic_cmpxchg_long:
          popl     %ebx
          ret
=
+.section .note.GNU-stack,"",%progbits

-------------- next part --------------
An embedded message was scrubbed...
From: Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?= <flameeyes at gmail.com>
Subject: [PATCH] Set GNU stack marking for non-executable stack on Linux
Date: Thu, 10 May 2007 22:20:17 +0200
Size: 4703
Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070510/b98e6aed/attachment.mht 

From neojia at gmail.com  Sun May 13 21:55:20 2007
From: neojia at gmail.com (Neo Jia)
Date: Sun, 13 May 2007 23:55:20 -0500
Subject: Running hotspot with valgrind to detect memory leak?
Message-ID: <5d649bdb0705132155n213259c0paefc17f9d660db80@mail.gmail.com>

hi,

For fun, I just ran the hotspot vm with valgrind memory checking. To
my surprise, valgrind has identified several "memory leak" inside vm.
Although there might be some false positive, I still would like to dig
a little bit.

For your reference, you may get the log file from the following link
since it is too huge to send through a mailing list. This tiny log
file is generated by running helloworld.java.

http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666
http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666.1

Thanks,
Neo
-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!


From flameeyes at gmail.com  Thu May 10 13:20:17 2007
From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=)
Date: Thu, 10 May 2007 22:20:17 +0200
Subject: [PATCH] Set GNU stack marking for non-executable stack on Linux
Message-ID: <20070510222017.295425e8@enterprise.flameeyes.is-a-geek.org>

The attached patch adds the GNU stack markings so that the stack is not
marked as RWX (both writable and executable). This is actually a minor
issues as with an enforced PaX (NX), Java will still not work because
of the JIT compiler, but at least it will remove one issue present
after building OpenJDK.

I'm not sure how the released binaries don't have the stacks marked as
executable, I suppose something might be mangling them afterward, but
this should cover the issue from the start.
The optimal way to handle this would have been to have it conditional
to Linux and ELF target, but that would have required to have
pre-processed sources (.S, rather than .s), and the two source files
are only for Linux (and thus only for ELF) anyway.

It also requires GNU as, but I think that is true already.

-- 
Diego "Flameeyes" Petten?
http://farragut.flameeyes.is-a-geek.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openjdk-execstac.patch
Type: text/x-patch
Size: 760 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070510/fee1d29d/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070510/fee1d29d/attachment-0001.bin 

From jc at egtc.com.cn  Tue May  8 19:26:29 2007
From: jc at egtc.com.cn (=?GB2312?B?s/7E/ta+?=)
Date: Wed, 09 May 2007 10:26:29 +0800
Subject: Bad links on openjdk website.
Message-ID: <46413155.6050903@egtc.com.cn>

Hi gurus,

"http://openjdk.java.net/groups/hotspot/" contains bad links and commands.

For instance:
...
"svn checkout https://openjdk.dev.java.net/svn/openjdk/hotspot/trunk"

It should be
"svn checkout https://openjdk.dev.java.net/svn/openjdk/jdk/trunk"
...


Regards,

Jacky






From Peter.Kessler at Sun.COM  Tue May 15 15:35:20 2007
From: Peter.Kessler at Sun.COM (Peter B. Kessler)
Date: Tue, 15 May 2007 15:35:20 -0700
Subject: Bad links on openjdk website.
In-Reply-To: <46413155.6050903@egtc.com.cn>
References: <46413155.6050903@egtc.com.cn>
Message-ID: <464A35A8.9050202@Sun.COM>

Thanks.  I'll fix those as soon as I figure out where we moved
the real pages too, now that we are on openjdk.java.net instead
of openjdk.dev.java.net.

			... peter

?????? wrote:
> Hi gurus,
> 
> "http://openjdk.java.net/groups/hotspot/" contains bad links and commands.
> 
> For instance:
> ...
> "svn checkout https://openjdk.dev.java.net/svn/openjdk/hotspot/trunk"
> 
> It should be
> "svn checkout https://openjdk.dev.java.net/svn/openjdk/jdk/trunk"
> ...
> 
> 
> Regards,
> 
> Jacky


From bnicolotti at siapcn.it  Wed May 16 01:37:46 2007
From: bnicolotti at siapcn.it (Bartolomeo Nicolotti)
Date: Wed, 16 May 2007 10:37:46 +0200 (CEST)
Subject: Is Hotspot  in the standard jdk
Message-ID: <27890.213.156.52.108.1179304666.squirrel@mail.siapcn.it>

Hallo,

I'd like to know if Hotspot is already present in the standard jdk (1.5 or
1.6).

Thanks in advance.

Bart


-- 
Bartolomeo Nicolotti
SIAP Sistemi Applicativi s.r.l.


From Peter.Kessler at Sun.COM  Wed May 16 08:32:16 2007
From: Peter.Kessler at Sun.COM (Peter B. Kessler)
Date: Wed, 16 May 2007 08:32:16 -0700
Subject: Is Hotspot  in the standard jdk
In-Reply-To: <27890.213.156.52.108.1179304666.squirrel@mail.siapcn.it>
References: <27890.213.156.52.108.1179304666.squirrel@mail.siapcn.it>
Message-ID: <464B2400.7040007@Sun.COM>

Bartolomeo Nicolotti wrote:
> Hallo,
> 
> I'd like to know if Hotspot is already present in the standard jdk (1.5 or
> 1.6).
> 
> Thanks in advance.
> 
> Bart

Sun's HotSpot virtual machine is the implementation of the
Java Standard Edition we ship for JDK 6 and JDK 1.5 (and on
back to some time in JDK 1.2.2).

			... peter


From john.pampuch at sun.com  Wed May 16 08:17:01 2007
From: john.pampuch at sun.com (John Pampuch)
Date: Wed, 16 May 2007 08:17:01 -0700
Subject: Is Hotspot  in the standard jdk
In-Reply-To: <27890.213.156.52.108.1179304666.squirrel@mail.siapcn.it>
References: <27890.213.156.52.108.1179304666.squirrel@mail.siapcn.it>
Message-ID: <464B206D.4010902@sun.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070516/6bdb4bcc/attachment.html 

From bero at arklinux.org  Wed May 16 08:00:24 2007
From: bero at arklinux.org (Bernhard Rosenkraenzer)
Date: Wed, 16 May 2007 17:00:24 +0200
Subject: Which parts of the binary blob are actually needed?
Message-ID: <200705161700.25638.bero@arklinux.org>

I've just had a look at the "full" openjdk release -- and noticed the binary 
blob is just about the size of the full jdk. I'm assuming it contains some 
unnecessary bits (e.g. bits that will be replaced with components that are 
built during the openjdk build process, such as the "java" and "javac" 
executables).

What parts of the blob actually make it to the final build? (And has anyone 
checked if they can be replaced with components from any of the free JDK 
reimplementations?)

Regards,
bero


From Steve.Goldman at Sun.COM  Wed May 16 10:17:30 2007
From: Steve.Goldman at Sun.COM (steve goldman)
Date: Wed, 16 May 2007 13:17:30 -0400
Subject: Which parts of the binary blob are actually needed?
In-Reply-To: <200705161700.25638.bero@arklinux.org>
References: <200705161700.25638.bero@arklinux.org>
Message-ID: <464B3CAA.4060405@sun.com>

Bernhard Rosenkraenzer wrote:
> I've just had a look at the "full" openjdk release -- and noticed the binary 
> blob is just about the size of the full jdk. I'm assuming it contains some 
> unnecessary bits (e.g. bits that will be replaced with components that are 
> built during the openjdk build process, such as the "java" and "javac" 
> executables).
> 
> What parts of the blob actually make it to the final build? (And has anyone 
> checked if they can be replaced with components from any of the free JDK 
> reimplementations?)

This mailing list is for jvm development. Some of us here can barely 
spell jdk let alone build it (speaking for myself certainly). I think 
you probably want to ask this on build-dev at openjdk.java.net

In addition I think all the mailing lists moved from 
... at openjdk.dev.java.net to ... at openjdk.java.net  as of JavaOne so 
people might want to update address books.

-- 
Steve


From Paul.Hohensee at Sun.COM  Wed May 16 10:04:40 2007
From: Paul.Hohensee at Sun.COM (Paul Hohensee - Java SE)
Date: Wed, 16 May 2007 13:04:40 -0400
Subject: Is Hotspot  in the standard jdk
In-Reply-To: <464B206D.4010902@sun.com>
References: <27890.213.156.52.108.1179304666.squirrel@mail.siapcn.it>
	<464B206D.4010902@sun.com>
Message-ID: <464B39A8.8080403@sun.com>

Perhaps what you're asking is whether the open source version of hotspot
is used in jdk1.4.2 and jdk5.  If so, the answer is no, those jdks contain
older versions of hotspot that haven't been open sourced.

Paul

John Pampuch wrote:
> Yes.  Both the server and client compilers are part of the JDK binary 
> distributions.  However, only the client compiler is delivered in the 
> JRE distribution today.
>
> -John
>
> Bartolomeo Nicolotti wrote:
>> Hallo,
>>
>> I'd like to know if Hotspot is already present in the standard jdk (1.5 or
>> 1.6).
>>
>> Thanks in advance.
>>
>> Bart
>>
>>
>>   


From Steve.Goldman at Sun.COM  Wed May 16 10:17:30 2007
From: Steve.Goldman at Sun.COM (steve goldman)
Date: Wed, 16 May 2007 13:17:30 -0400
Subject: Which parts of the binary blob are actually needed?
In-Reply-To: <200705161700.25638.bero@arklinux.org>
References: <200705161700.25638.bero@arklinux.org>
Message-ID: <464B3CAA.4060405@sun.com>

Bernhard Rosenkraenzer wrote:
> I've just had a look at the "full" openjdk release -- and noticed the binary 
> blob is just about the size of the full jdk. I'm assuming it contains some 
> unnecessary bits (e.g. bits that will be replaced with components that are 
> built during the openjdk build process, such as the "java" and "javac" 
> executables).
> 
> What parts of the blob actually make it to the final build? (And has anyone 
> checked if they can be replaced with components from any of the free JDK 
> reimplementations?)

This mailing list is for jvm development. Some of us here can barely 
spell jdk let alone build it (speaking for myself certainly). I think 
you probably want to ask this on build-dev at openjdk.java.net

In addition I think all the mailing lists moved from 
... at openjdk.dev.java.net to ... at openjdk.java.net  as of JavaOne so 
people might want to update address books.

-- 
Steve


From Kelly.Ohair at Sun.COM  Wed May 16 13:58:33 2007
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Wed, 16 May 2007 13:58:33 -0700
Subject: Which parts of the binary blob are actually needed?
In-Reply-To: <200705161700.25638.bero@arklinux.org>
References: <200705161700.25638.bero@arklinux.org>
Message-ID: <464B7079.5050109@sun.com>


Unofficial list is:

Binary Libraries:

  lib/i386/libt2k.so    (or bin/t2k.dll)
  lib/i386/libdcpr.so   (or bin/dcpr.dll)
  lib/i386/libjsound.so (or bin/jsound.dll) and libjsoundalsa.so on Linux?

Security Jar Files:

  lib/jce.jar
  lib/ext/sunjce_provider.jar
  lib/security/US_export_policy.jar
  lib/security/local_policy.jar

Classes From rt.jar:

   com/sun/jmx/snmp/SnmpDataTypeEnums.class
   com/sun/jmx/snmp/SnmpDefinitions.class
   com/sun/jmx/snmp/SnmpOid.class
   com/sun/jmx/snmp/SnmpOidDatabase.class
   com/sun/jmx/snmp/SnmpOidDatabaseSupport.class
   com/sun/jmx/snmp/SnmpOidRecord.class
   com/sun/jmx/snmp/SnmpOidTable.class
   com/sun/jmx/snmp/SnmpOidTableSupport.class
   com/sun/jmx/snmp/SnmpParameters.class
   com/sun/jmx/snmp/SnmpPduPacket.class
   com/sun/jmx/snmp/SnmpPeer.class
   com/sun/jmx/snmp/SnmpTimeticks.class
   com/sun/jmx/snmp/SnmpVarBind.class
   com/sun/jmx/snmp/SnmpVarBindList.class
   com/sun/jmx/snmp/Timestamp.class
   com/sun/jmx/snmp/daemon/SendQ.class
   com/sun/jmx/snmp/daemon/SnmpInformRequest.class
   com/sun/jmx/snmp/daemon/SnmpQManager.class
   com/sun/jmx/snmp/daemon/SnmpRequestCounter.class
   com/sun/jmx/snmp/daemon/SnmpResponseHandler.class
   com/sun/jmx/snmp/daemon/SnmpSendServer.class
   com/sun/jmx/snmp/daemon/SnmpSession.class
   com/sun/jmx/snmp/daemon/SnmpSocket.class
   com/sun/jmx/snmp/daemon/SnmpTimerServer.class
   com/sun/jmx/snmp/daemon/WaitQ.class
   com/sun/media/sound/AbstractDataLine.class
   com/sun/media/sound/AbstractLine.class
   com/sun/media/sound/AbstractMidiDevice$AbstractReceiver.class
   com/sun/media/sound/AbstractMidiDevice$BasicTransmitter.class
   com/sun/media/sound/AbstractMidiDevice$TransmitterList.class
   com/sun/media/sound/AbstractMidiDevice.class
   com/sun/media/sound/AbstractMidiDeviceProvider$Info.class
   com/sun/media/sound/AbstractMidiDeviceProvider.class
   com/sun/media/sound/AbstractMixer.class
   com/sun/media/sound/AbstractPlayer.class
   com/sun/media/sound/AiffFileFormat.class
   com/sun/media/sound/AiffFileReader.class
   com/sun/media/sound/AiffFileWriter.class
   com/sun/media/sound/AlawCodec$AlawCodecStream.class
   com/sun/media/sound/AlawCodec.class
   com/sun/media/sound/AuFileFormat.class
   com/sun/media/sound/AuFileReader.class
   com/sun/media/sound/AuFileWriter.class
   com/sun/media/sound/AutoClosingClip.class
   com/sun/media/sound/AutoConnectSequencer.class
   com/sun/media/sound/CircularBuffer.class
   com/sun/media/sound/DataPusher.class
   com/sun/media/sound/DirectAudioDevice$1.class
   com/sun/media/sound/DirectAudioDevice$DirectBAOS.class
   com/sun/media/sound/DirectAudioDevice$DirectClip.class
   com/sun/media/sound/DirectAudioDevice$DirectDL$Balance.class
   com/sun/media/sound/DirectAudioDevice$DirectDL$Gain.class
   com/sun/media/sound/DirectAudioDevice$DirectDL$Mute.class
   com/sun/media/sound/DirectAudioDevice$DirectDL$Pan.class
   com/sun/media/sound/DirectAudioDevice$DirectDL.class
   com/sun/media/sound/DirectAudioDevice$DirectDLI.class
   com/sun/media/sound/DirectAudioDevice$DirectSDL.class
   com/sun/media/sound/DirectAudioDevice$DirectTDL.class
   com/sun/media/sound/DirectAudioDevice.class
   com/sun/media/sound/DirectAudioDeviceProvider$DirectAudioDeviceInfo.class
   com/sun/media/sound/DirectAudioDeviceProvider.class
   com/sun/media/sound/EventDispatcher$ClipInfo.class
   com/sun/media/sound/EventDispatcher$EventInfo.class
   com/sun/media/sound/EventDispatcher$LineMonitor.class
   com/sun/media/sound/EventDispatcher.class
   com/sun/media/sound/FastShortMessage.class
   com/sun/media/sound/FastSysexMessage.class
   com/sun/media/sound/HeadspaceInstrument.class
   com/sun/media/sound/HeadspaceMixer$1.class
   com/sun/media/sound/HeadspaceMixer$MidiLine.class
   com/sun/media/sound/HeadspaceMixer$MidiLineInfo.class
   com/sun/media/sound/HeadspaceMixer$MixerInfo.class
   com/sun/media/sound/HeadspaceMixer$MixerReverbControl$MixerReverbType.class
   com/sun/media/sound/HeadspaceMixer$MixerReverbControl.class
   com/sun/media/sound/HeadspaceMixer.class
   com/sun/media/sound/HeadspaceMixerProvider.class
   com/sun/media/sound/HeadspaceSample.class
   com/sun/media/sound/HeadspaceSoundbank.class
   com/sun/media/sound/HsbParser.class
   com/sun/media/sound/JDK13Services$1.class
   com/sun/media/sound/JDK13Services$ProviderCache.class
   com/sun/media/sound/JDK13Services.class
   com/sun/media/sound/JSSecurityManager$1.class
   com/sun/media/sound/JSSecurityManager$2.class
   com/sun/media/sound/JSSecurityManager$3.class
   com/sun/media/sound/JSSecurityManager$4.class
   com/sun/media/sound/JSSecurityManager$5.class
   com/sun/media/sound/JSSecurityManager$6.class
   com/sun/media/sound/JSSecurityManager$7.class
   com/sun/media/sound/JSSecurityManager.class
   com/sun/media/sound/JavaSoundAudioClip$DirectBAOS.class
   com/sun/media/sound/JavaSoundAudioClip.class
   com/sun/media/sound/MidiInDevice$1.class
   com/sun/media/sound/MidiInDevice$MidiInTransmitter.class
   com/sun/media/sound/MidiInDevice.class
   com/sun/media/sound/MidiInDeviceProvider$1.class
   com/sun/media/sound/MidiInDeviceProvider$MidiInDeviceInfo.class
   com/sun/media/sound/MidiInDeviceProvider.class
   com/sun/media/sound/MidiOutDevice$MidiOutReceiver.class
   com/sun/media/sound/MidiOutDevice.class
   com/sun/media/sound/MidiOutDeviceProvider$1.class
   com/sun/media/sound/MidiOutDeviceProvider$MidiOutDeviceInfo.class
   com/sun/media/sound/MidiOutDeviceProvider.class
   com/sun/media/sound/MidiUtils$TempoCache.class
   com/sun/media/sound/MidiUtils.class
   com/sun/media/sound/MixerClip$1.class
   com/sun/media/sound/MixerClip$MixerClipApplyReverbControl.class
   com/sun/media/sound/MixerClip$MixerClipGainControl.class
   com/sun/media/sound/MixerClip$MixerClipMuteControl.class
   com/sun/media/sound/MixerClip$MixerClipPanControl.class
   com/sun/media/sound/MixerClip$MixerClipSampleRateControl.class
   com/sun/media/sound/MixerClip.class
   com/sun/media/sound/MixerMidiChannel.class
   com/sun/media/sound/MixerSequencer$1.class
   com/sun/media/sound/MixerSequencer$ControllerVectorElement.class
   com/sun/media/sound/MixerSequencer$MixerSequencerInfo.class
   com/sun/media/sound/MixerSequencer$RecordingTrack.class
   com/sun/media/sound/MixerSequencer.class
   com/sun/media/sound/MixerSequencerProvider.class
   com/sun/media/sound/MixerSourceLine$1.class
   com/sun/media/sound/MixerSourceLine$MixerSourceLineApplyReverbControl.class
   com/sun/media/sound/MixerSourceLine$MixerSourceLineGainControl.class
   com/sun/media/sound/MixerSourceLine$MixerSourceLineMuteControl.class
   com/sun/media/sound/MixerSourceLine$MixerSourceLinePanControl.class
   com/sun/media/sound/MixerSourceLine$MixerSourceLineSampleRateControl.class
   com/sun/media/sound/MixerSourceLine.class
   com/sun/media/sound/MixerSynth$1.class
   com/sun/media/sound/MixerSynth$MixerSynthInfo.class
   com/sun/media/sound/MixerSynth$SynthReceiver.class
   com/sun/media/sound/MixerSynth.class
   com/sun/media/sound/MixerSynthProvider.class
   com/sun/media/sound/MixerThread.class
   com/sun/media/sound/PCMtoPCMCodec$PCMtoPCMCodecStream.class
   com/sun/media/sound/PCMtoPCMCodec.class
   com/sun/media/sound/Platform.class
   com/sun/media/sound/PortMixer$1.class
   com/sun/media/sound/PortMixer$BoolCtrl$BCT.class
   com/sun/media/sound/PortMixer$BoolCtrl.class
   com/sun/media/sound/PortMixer$CompCtrl$CCT.class
   com/sun/media/sound/PortMixer$CompCtrl.class
   com/sun/media/sound/PortMixer$FloatCtrl$FCT.class
   com/sun/media/sound/PortMixer$FloatCtrl.class
   com/sun/media/sound/PortMixer$PortInfo.class
   com/sun/media/sound/PortMixer$PortMixerPort.class
   com/sun/media/sound/PortMixer.class
   com/sun/media/sound/PortMixerProvider$PortMixerInfo.class
   com/sun/media/sound/PortMixerProvider.class
   com/sun/media/sound/Printer.class
   com/sun/media/sound/RealTimeSequencer$1.class
   com/sun/media/sound/RealTimeSequencer$ControllerListElement.class
   com/sun/media/sound/RealTimeSequencer$DataPump.class
   com/sun/media/sound/RealTimeSequencer$PlayThread.class
   com/sun/media/sound/RealTimeSequencer$RealTimeSequencerInfo.class
   com/sun/media/sound/RealTimeSequencer$RecordingTrack.class
   com/sun/media/sound/RealTimeSequencer$SequencerReceiver.class
   com/sun/media/sound/RealTimeSequencer$SequencerTransmitter.class
   com/sun/media/sound/RealTimeSequencer.class
   com/sun/media/sound/RealTimeSequencerProvider.class
   com/sun/media/sound/ReferenceCountingDevice.class
   com/sun/media/sound/RmfFileReader.class
   com/sun/media/sound/SMFParser.class
   com/sun/media/sound/SimpleInputDevice$1.class
   com/sun/media/sound/SimpleInputDevice$InputDeviceDataLine.class
   com/sun/media/sound/SimpleInputDevice$InputDevicePort.class
   com/sun/media/sound/SimpleInputDevice$InputDevicePortInfo.class
   com/sun/media/sound/SimpleInputDevice.class
   com/sun/media/sound/SimpleInputDeviceProvider$1.class
   com/sun/media/sound/SimpleInputDeviceProvider$InputDeviceInfo.class
   com/sun/media/sound/SimpleInputDeviceProvider.class
   com/sun/media/sound/StandardMidiFileReader.class
   com/sun/media/sound/StandardMidiFileWriter.class
   com/sun/media/sound/SunCodec.class
   com/sun/media/sound/SunFileReader.class
   com/sun/media/sound/SunFileWriter.class
   com/sun/media/sound/Toolkit.class
   com/sun/media/sound/UlawCodec$UlawCodecStream.class
   com/sun/media/sound/UlawCodec.class
   com/sun/media/sound/WaveFileFormat.class
   com/sun/media/sound/WaveFileReader.class
   com/sun/media/sound/WaveFileWriter.class
   java/awt/color/CMMException.class
   java/awt/color/ColorSpace.class
   java/awt/color/ICC_ColorSpace.class
   java/awt/color/ICC_Profile$1.class
   java/awt/color/ICC_Profile$2.class
   java/awt/color/ICC_Profile$3.class
   java/awt/color/ICC_Profile.class
   java/awt/color/ICC_ProfileGray.class
   java/awt/color/ICC_ProfileRGB.class
   java/awt/image/BandedSampleModel.class
   java/awt/image/ColorConvertOp.class
   java/awt/image/ComponentSampleModel.class
   java/awt/image/DataBuffer$1.class
   java/awt/image/DataBuffer.class
   java/awt/image/DataBufferByte.class
   java/awt/image/DataBufferInt.class
   java/awt/image/DataBufferShort.class
   java/awt/image/DataBufferUShort.class
   java/awt/image/MultiPixelPackedSampleModel.class
   java/awt/image/Raster.class
   java/awt/image/RenderedImage.class
   java/awt/image/SampleModel.class
   java/awt/image/SinglePixelPackedSampleModel.class
   java/awt/image/WritableRaster.class
   java/awt/image/WritableRenderedImage.class
   java/awt/image/renderable/ContextualRenderedImageFactory.class
   java/awt/image/renderable/ParameterBlock.class
   java/awt/image/renderable/RenderContext.class
   java/awt/image/renderable/RenderableImage.class
   java/awt/image/renderable/RenderableImageOp.class
   java/awt/image/renderable/RenderableImageProducer.class
   java/awt/image/renderable/RenderedImageFactory.class
   sun/dc/path/FastPathProducer.class
   sun/dc/path/PathConsumer.class
   sun/dc/path/PathError.class
   sun/dc/path/PathException.class
   sun/dc/pr/PRError.class
   sun/dc/pr/PRException.class
   sun/dc/pr/PathDasher.class
   sun/dc/pr/PathFiller.class
   sun/dc/pr/PathStroker.class
   sun/dc/pr/Rasterizer$ConsumerDisposer.class
   sun/dc/pr/Rasterizer.class

-The End-

-kto


Bernhard Rosenkraenzer wrote:
> I've just had a look at the "full" openjdk release -- and noticed the binary 
> blob is just about the size of the full jdk. I'm assuming it contains some 
> unnecessary bits (e.g. bits that will be replaced with components that are 
> built during the openjdk build process, such as the "java" and "javac" 
> executables).
> 
> What parts of the blob actually make it to the final build? (And has anyone 
> checked if they can be replaced with components from any of the free JDK 
> reimplementations?)
> 
> Regards,
> bero


From gnu_andrew at member.fsf.org  Wed May 16 14:37:49 2007
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 16 May 2007 22:37:49 +0100
Subject: Which parts of the binary blob are actually needed?
In-Reply-To: <464B7079.5050109@sun.com>
References: <200705161700.25638.bero@arklinux.org> <464B7079.5050109@sun.com>
Message-ID: <200705162237.58372.gnu_andrew@member.fsf.org>

On Wednesday 16 May 2007 21:58, Kelly O'Hair wrote:
> Unofficial list is:
>
> Binary Libraries:
>
>   lib/i386/libt2k.so    (or bin/t2k.dll)
>   lib/i386/libdcpr.so   (or bin/dcpr.dll)
>   lib/i386/libjsound.so (or bin/jsound.dll) and libjsoundalsa.so on Linux?
>
> Security Jar Files:
>
>   lib/jce.jar
>   lib/ext/sunjce_provider.jar
>   lib/security/US_export_policy.jar
>   lib/security/local_policy.jar
>
> Classes From rt.jar:
>
>    com/sun/jmx/snmp/SnmpDataTypeEnums.class
>    com/sun/jmx/snmp/SnmpDefinitions.class
>    com/sun/jmx/snmp/SnmpOid.class
>    com/sun/jmx/snmp/SnmpOidDatabase.class
>    com/sun/jmx/snmp/SnmpOidDatabaseSupport.class
>    com/sun/jmx/snmp/SnmpOidRecord.class
>    com/sun/jmx/snmp/SnmpOidTable.class
>    com/sun/jmx/snmp/SnmpOidTableSupport.class
>    com/sun/jmx/snmp/SnmpParameters.class
>    com/sun/jmx/snmp/SnmpPduPacket.class
>    com/sun/jmx/snmp/SnmpPeer.class
>    com/sun/jmx/snmp/SnmpTimeticks.class
>    com/sun/jmx/snmp/SnmpVarBind.class
>    com/sun/jmx/snmp/SnmpVarBindList.class
>    com/sun/jmx/snmp/Timestamp.class
>    com/sun/jmx/snmp/daemon/SendQ.class
>    com/sun/jmx/snmp/daemon/SnmpInformRequest.class
>    com/sun/jmx/snmp/daemon/SnmpQManager.class
>    com/sun/jmx/snmp/daemon/SnmpRequestCounter.class
>    com/sun/jmx/snmp/daemon/SnmpResponseHandler.class
>    com/sun/jmx/snmp/daemon/SnmpSendServer.class
>    com/sun/jmx/snmp/daemon/SnmpSession.class
>    com/sun/jmx/snmp/daemon/SnmpSocket.class
>    com/sun/jmx/snmp/daemon/SnmpTimerServer.class
>    com/sun/jmx/snmp/daemon/WaitQ.class
>    com/sun/media/sound/AbstractDataLine.class
>    com/sun/media/sound/AbstractLine.class
>    com/sun/media/sound/AbstractMidiDevice$AbstractReceiver.class
>    com/sun/media/sound/AbstractMidiDevice$BasicTransmitter.class
>    com/sun/media/sound/AbstractMidiDevice$TransmitterList.class
>    com/sun/media/sound/AbstractMidiDevice.class
>    com/sun/media/sound/AbstractMidiDeviceProvider$Info.class
>    com/sun/media/sound/AbstractMidiDeviceProvider.class
>    com/sun/media/sound/AbstractMixer.class
>    com/sun/media/sound/AbstractPlayer.class
>    com/sun/media/sound/AiffFileFormat.class
>    com/sun/media/sound/AiffFileReader.class
>    com/sun/media/sound/AiffFileWriter.class
>    com/sun/media/sound/AlawCodec$AlawCodecStream.class
>    com/sun/media/sound/AlawCodec.class
>    com/sun/media/sound/AuFileFormat.class
>    com/sun/media/sound/AuFileReader.class
>    com/sun/media/sound/AuFileWriter.class
>    com/sun/media/sound/AutoClosingClip.class
>    com/sun/media/sound/AutoConnectSequencer.class
>    com/sun/media/sound/CircularBuffer.class
>    com/sun/media/sound/DataPusher.class
>    com/sun/media/sound/DirectAudioDevice$1.class
>    com/sun/media/sound/DirectAudioDevice$DirectBAOS.class
>    com/sun/media/sound/DirectAudioDevice$DirectClip.class
>    com/sun/media/sound/DirectAudioDevice$DirectDL$Balance.class
>    com/sun/media/sound/DirectAudioDevice$DirectDL$Gain.class
>    com/sun/media/sound/DirectAudioDevice$DirectDL$Mute.class
>    com/sun/media/sound/DirectAudioDevice$DirectDL$Pan.class
>    com/sun/media/sound/DirectAudioDevice$DirectDL.class
>    com/sun/media/sound/DirectAudioDevice$DirectDLI.class
>    com/sun/media/sound/DirectAudioDevice$DirectSDL.class
>    com/sun/media/sound/DirectAudioDevice$DirectTDL.class
>    com/sun/media/sound/DirectAudioDevice.class
>   
> com/sun/media/sound/DirectAudioDeviceProvider$DirectAudioDeviceInfo.class
> com/sun/media/sound/DirectAudioDeviceProvider.class
>    com/sun/media/sound/EventDispatcher$ClipInfo.class
>    com/sun/media/sound/EventDispatcher$EventInfo.class
>    com/sun/media/sound/EventDispatcher$LineMonitor.class
>    com/sun/media/sound/EventDispatcher.class
>    com/sun/media/sound/FastShortMessage.class
>    com/sun/media/sound/FastSysexMessage.class
>    com/sun/media/sound/HeadspaceInstrument.class
>    com/sun/media/sound/HeadspaceMixer$1.class
>    com/sun/media/sound/HeadspaceMixer$MidiLine.class
>    com/sun/media/sound/HeadspaceMixer$MidiLineInfo.class
>    com/sun/media/sound/HeadspaceMixer$MixerInfo.class
>   
> com/sun/media/sound/HeadspaceMixer$MixerReverbControl$MixerReverbType.class
> com/sun/media/sound/HeadspaceMixer$MixerReverbControl.class
>    com/sun/media/sound/HeadspaceMixer.class
>    com/sun/media/sound/HeadspaceMixerProvider.class
>    com/sun/media/sound/HeadspaceSample.class
>    com/sun/media/sound/HeadspaceSoundbank.class
>    com/sun/media/sound/HsbParser.class
>    com/sun/media/sound/JDK13Services$1.class
>    com/sun/media/sound/JDK13Services$ProviderCache.class
>    com/sun/media/sound/JDK13Services.class
>    com/sun/media/sound/JSSecurityManager$1.class
>    com/sun/media/sound/JSSecurityManager$2.class
>    com/sun/media/sound/JSSecurityManager$3.class
>    com/sun/media/sound/JSSecurityManager$4.class
>    com/sun/media/sound/JSSecurityManager$5.class
>    com/sun/media/sound/JSSecurityManager$6.class
>    com/sun/media/sound/JSSecurityManager$7.class
>    com/sun/media/sound/JSSecurityManager.class
>    com/sun/media/sound/JavaSoundAudioClip$DirectBAOS.class
>    com/sun/media/sound/JavaSoundAudioClip.class
>    com/sun/media/sound/MidiInDevice$1.class
>    com/sun/media/sound/MidiInDevice$MidiInTransmitter.class
>    com/sun/media/sound/MidiInDevice.class
>    com/sun/media/sound/MidiInDeviceProvider$1.class
>    com/sun/media/sound/MidiInDeviceProvider$MidiInDeviceInfo.class
>    com/sun/media/sound/MidiInDeviceProvider.class
>    com/sun/media/sound/MidiOutDevice$MidiOutReceiver.class
>    com/sun/media/sound/MidiOutDevice.class
>    com/sun/media/sound/MidiOutDeviceProvider$1.class
>    com/sun/media/sound/MidiOutDeviceProvider$MidiOutDeviceInfo.class
>    com/sun/media/sound/MidiOutDeviceProvider.class
>    com/sun/media/sound/MidiUtils$TempoCache.class
>    com/sun/media/sound/MidiUtils.class
>    com/sun/media/sound/MixerClip$1.class
>    com/sun/media/sound/MixerClip$MixerClipApplyReverbControl.class
>    com/sun/media/sound/MixerClip$MixerClipGainControl.class
>    com/sun/media/sound/MixerClip$MixerClipMuteControl.class
>    com/sun/media/sound/MixerClip$MixerClipPanControl.class
>    com/sun/media/sound/MixerClip$MixerClipSampleRateControl.class
>    com/sun/media/sound/MixerClip.class
>    com/sun/media/sound/MixerMidiChannel.class
>    com/sun/media/sound/MixerSequencer$1.class
>    com/sun/media/sound/MixerSequencer$ControllerVectorElement.class
>    com/sun/media/sound/MixerSequencer$MixerSequencerInfo.class
>    com/sun/media/sound/MixerSequencer$RecordingTrack.class
>    com/sun/media/sound/MixerSequencer.class
>    com/sun/media/sound/MixerSequencerProvider.class
>    com/sun/media/sound/MixerSourceLine$1.class
>   
> com/sun/media/sound/MixerSourceLine$MixerSourceLineApplyReverbControl.class
> com/sun/media/sound/MixerSourceLine$MixerSourceLineGainControl.class
> com/sun/media/sound/MixerSourceLine$MixerSourceLineMuteControl.class
> com/sun/media/sound/MixerSourceLine$MixerSourceLinePanControl.class
> com/sun/media/sound/MixerSourceLine$MixerSourceLineSampleRateControl.class
> com/sun/media/sound/MixerSourceLine.class
>    com/sun/media/sound/MixerSynth$1.class
>    com/sun/media/sound/MixerSynth$MixerSynthInfo.class
>    com/sun/media/sound/MixerSynth$SynthReceiver.class
>    com/sun/media/sound/MixerSynth.class
>    com/sun/media/sound/MixerSynthProvider.class
>    com/sun/media/sound/MixerThread.class
>    com/sun/media/sound/PCMtoPCMCodec$PCMtoPCMCodecStream.class
>    com/sun/media/sound/PCMtoPCMCodec.class
>    com/sun/media/sound/Platform.class
>    com/sun/media/sound/PortMixer$1.class
>    com/sun/media/sound/PortMixer$BoolCtrl$BCT.class
>    com/sun/media/sound/PortMixer$BoolCtrl.class
>    com/sun/media/sound/PortMixer$CompCtrl$CCT.class
>    com/sun/media/sound/PortMixer$CompCtrl.class
>    com/sun/media/sound/PortMixer$FloatCtrl$FCT.class
>    com/sun/media/sound/PortMixer$FloatCtrl.class
>    com/sun/media/sound/PortMixer$PortInfo.class
>    com/sun/media/sound/PortMixer$PortMixerPort.class
>    com/sun/media/sound/PortMixer.class
>    com/sun/media/sound/PortMixerProvider$PortMixerInfo.class
>    com/sun/media/sound/PortMixerProvider.class
>    com/sun/media/sound/Printer.class
>    com/sun/media/sound/RealTimeSequencer$1.class
>    com/sun/media/sound/RealTimeSequencer$ControllerListElement.class
>    com/sun/media/sound/RealTimeSequencer$DataPump.class
>    com/sun/media/sound/RealTimeSequencer$PlayThread.class
>    com/sun/media/sound/RealTimeSequencer$RealTimeSequencerInfo.class
>    com/sun/media/sound/RealTimeSequencer$RecordingTrack.class
>    com/sun/media/sound/RealTimeSequencer$SequencerReceiver.class
>    com/sun/media/sound/RealTimeSequencer$SequencerTransmitter.class
>    com/sun/media/sound/RealTimeSequencer.class
>    com/sun/media/sound/RealTimeSequencerProvider.class
>    com/sun/media/sound/ReferenceCountingDevice.class
>    com/sun/media/sound/RmfFileReader.class
>    com/sun/media/sound/SMFParser.class
>    com/sun/media/sound/SimpleInputDevice$1.class
>    com/sun/media/sound/SimpleInputDevice$InputDeviceDataLine.class
>    com/sun/media/sound/SimpleInputDevice$InputDevicePort.class
>    com/sun/media/sound/SimpleInputDevice$InputDevicePortInfo.class
>    com/sun/media/sound/SimpleInputDevice.class
>    com/sun/media/sound/SimpleInputDeviceProvider$1.class
>    com/sun/media/sound/SimpleInputDeviceProvider$InputDeviceInfo.class
>    com/sun/media/sound/SimpleInputDeviceProvider.class
>    com/sun/media/sound/StandardMidiFileReader.class
>    com/sun/media/sound/StandardMidiFileWriter.class
>    com/sun/media/sound/SunCodec.class
>    com/sun/media/sound/SunFileReader.class
>    com/sun/media/sound/SunFileWriter.class
>    com/sun/media/sound/Toolkit.class
>    com/sun/media/sound/UlawCodec$UlawCodecStream.class
>    com/sun/media/sound/UlawCodec.class
>    com/sun/media/sound/WaveFileFormat.class
>    com/sun/media/sound/WaveFileReader.class
>    com/sun/media/sound/WaveFileWriter.class
>    java/awt/color/CMMException.class
>    java/awt/color/ColorSpace.class
>    java/awt/color/ICC_ColorSpace.class
>    java/awt/color/ICC_Profile$1.class
>    java/awt/color/ICC_Profile$2.class
>    java/awt/color/ICC_Profile$3.class
>    java/awt/color/ICC_Profile.class
>    java/awt/color/ICC_ProfileGray.class
>    java/awt/color/ICC_ProfileRGB.class
>    java/awt/image/BandedSampleModel.class
>    java/awt/image/ColorConvertOp.class
>    java/awt/image/ComponentSampleModel.class
>    java/awt/image/DataBuffer$1.class
>    java/awt/image/DataBuffer.class
>    java/awt/image/DataBufferByte.class
>    java/awt/image/DataBufferInt.class
>    java/awt/image/DataBufferShort.class
>    java/awt/image/DataBufferUShort.class
>    java/awt/image/MultiPixelPackedSampleModel.class
>    java/awt/image/Raster.class
>    java/awt/image/RenderedImage.class
>    java/awt/image/SampleModel.class
>    java/awt/image/SinglePixelPackedSampleModel.class
>    java/awt/image/WritableRaster.class
>    java/awt/image/WritableRenderedImage.class
>    java/awt/image/renderable/ContextualRenderedImageFactory.class
>    java/awt/image/renderable/ParameterBlock.class
>    java/awt/image/renderable/RenderContext.class
>    java/awt/image/renderable/RenderableImage.class
>    java/awt/image/renderable/RenderableImageOp.class
>    java/awt/image/renderable/RenderableImageProducer.class
>    java/awt/image/renderable/RenderedImageFactory.class
>    sun/dc/path/FastPathProducer.class
>    sun/dc/path/PathConsumer.class
>    sun/dc/path/PathError.class
>    sun/dc/path/PathException.class
>    sun/dc/pr/PRError.class
>    sun/dc/pr/PRException.class
>    sun/dc/pr/PathDasher.class
>    sun/dc/pr/PathFiller.class
>    sun/dc/pr/PathStroker.class
>    sun/dc/pr/Rasterizer$ConsumerDisposer.class
>    sun/dc/pr/Rasterizer.class
>
> -The End-
>
> -kto
>
> Bernhard Rosenkraenzer wrote:
> > I've just had a look at the "full" openjdk release -- and noticed the
> > binary blob is just about the size of the full jdk. I'm assuming it
> > contains some unnecessary bits (e.g. bits that will be replaced with
> > components that are built during the openjdk build process, such as the
> > "java" and "javac" executables).
> >
> > What parts of the blob actually make it to the final build? (And has
> > anyone checked if they can be replaced with components from any of the
> > free JDK reimplementations?)
> >
> > Regards,
> > bero

A number of the GNU Classpath developers (including myself) are looking into 
how OpenJDK can be built, in its present form, without the binary 
dependencies, through various methods such as using bits of Classpath, 
breaking of small chunks, etc.  Sun is also of course working towards this in 
the long term, with the community when a process of committing patches is 
established.
-- 
Andrew :-)

Help end the Java Trap!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070516/3cb6c7d5/attachment.bin 

From dfabulich at warpmail.net  Thu May 17 22:42:44 2007
From: dfabulich at warpmail.net (Dan Fabulich)
Date: Thu, 17 May 2007 22:42:44 -0700 (Pacific Daylight Time)
Subject: Which parts of the binary blob are actually needed?
In-Reply-To: <464B7079.5050109@sun.com>
References: <200705161700.25638.bero@arklinux.org> <464B7079.5050109@sun.com>
Message-ID: <Pine.WNT.4.63.0705172241170.3856@tbf>

Kelly O'Hair wrote:

> Binary Libraries:
>
> lib/i386/libt2k.so    (or bin/t2k.dll)

Don't forget that you can't build OpenJDK on Windows because you need 
t2k.lib, not t2k.dll.  t2k.lib is not distributed in the Windows binary 
plugs, so doing a build on that platform is impossible.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6555215

-Dan


From Tom.Marble at Sun.COM  Sun May 20 13:25:58 2007
From: Tom.Marble at Sun.COM (Tom Marble)
Date: Sun, 20 May 2007 15:25:58 -0500
Subject: test of new Gmane migration
Message-ID: <4650AED6.8000609@sun.com>

All:

Please ignore this test message whose purpose is
to confirm that the Gmane gateway has been migrated
from the old list to the new list.

--Tom


From ted at tedneward.com  Sun May 20 12:26:54 2007
From: ted at tedneward.com (Ted Neward)
Date: Sun, 20 May 2007 12:26:54 -0700
Subject: Which parts of the binary blob are actually needed?
In-Reply-To: <Pine.WNT.4.63.0705172241170.3856@tbf>
Message-ID: <007201c79b14$d548d5c0$802ca8c0@XPWork>

Why is that? And is there someplace else one can find the t2k.dll?

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
 
> -----Original Message-----
> From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-
> bounces at openjdk.java.net] On Behalf Of Dan Fabulich
> Sent: Thursday, May 17, 2007 10:43 PM
> To: Kelly O'Hair
> Cc: build-dev at openjdk.java.net; hotspot-dev at openjdk.dev.java.net
> Subject: Re: Which parts of the binary blob are actually needed?
> 
> Kelly O'Hair wrote:
> 
> > Binary Libraries:
> >
> > lib/i386/libt2k.so    (or bin/t2k.dll)
> 
> Don't forget that you can't build OpenJDK on Windows because you need
> t2k.lib, not t2k.dll.  t2k.lib is not distributed in the Windows binary
> plugs, so doing a build on that platform is impossible.
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6555215
> 
> -Dan
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: 5/15/2007
> 10:47 AM
> 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.467 / Virus Database: 269.7.6/813 - Release Date: 5/20/2007
7:54 AM
 


From Sandeep.Konchady at Sun.COM  Sun May 20 20:27:59 2007
From: Sandeep.Konchady at Sun.COM (Sandeep Konchady)
Date: Sun, 20 May 2007 20:27:59 -0700
Subject: Running hotspot with valgrind to detect memory leak?
In-Reply-To: <5d649bdb0705132155n213259c0paefc17f9d660db80@mail.gmail.com>
References: <5d649bdb0705132155n213259c0paefc17f9d660db80@mail.gmail.com>
Message-ID: <465111BF.5060502@Sun.COM>

Hi,

    Extending what Neo Jia ran on JVM, I tested OpenJDK VM with Valgrind 
using MemoryMonitor demo. To my surprise I got a HotSpot crash in 
nmethod.cpp. I am attaching hs_err log file to this email and can give 
the Valgrind log if needed. Also I was unable to find similar report on 
SDN bug database.

#  Internal Error (nmethod.cpp:1822), pid=6946, tid=80788368
#  Error: guarantee(cont_offset != 0,"unhandled implicit exception in 
compiled code")

Thanks,
Sandeep

Neo Jia wrote:
> hi,
>
> For fun, I just ran the hotspot vm with valgrind memory checking. To
> my surprise, valgrind has identified several "memory leak" inside vm.
> Although there might be some false positive, I still would like to dig
> a little bit.
>
> For your reference, you may get the log file from the following link
> since it is too huge to send through a mailing list. This tiny log
> file is generated by running helloworld.java.
>
> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666 
>
> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666.1 
>
>
> Thanks,
> Neo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hs_err_pid6946.log
Type: text/x-log
Size: 31673 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070520/49e6b5f2/attachment.bin 

From neojia at gmail.com  Sun May 20 22:50:50 2007
From: neojia at gmail.com (Neo Jia)
Date: Mon, 21 May 2007 00:50:50 -0500
Subject: Running hotspot with valgrind to detect memory leak?
In-Reply-To: <465111BF.5060502@Sun.COM>
References: <5d649bdb0705132155n213259c0paefc17f9d660db80@mail.gmail.com>
	<465111BF.5060502@Sun.COM>
Message-ID: <5d649bdb0705202250j5231b367tf911e9669bb6a994@mail.gmail.com>

On 5/20/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
> Hi,
>
>     Extending what Neo Jia ran on JVM, I tested OpenJDK VM with Valgrind
> using MemoryMonitor demo. To my surprise I got a HotSpot crash in
> nmethod.cpp. I am attaching hs_err log file to this email and can give
> the Valgrind log if needed. Also I was unable to find similar report on
> SDN bug database.
>
> #  Internal Error (nmethod.cpp:1822), pid=6946, tid=80788368
> #  Error: guarantee(cont_offset != 0,"unhandled implicit exception in
> compiled code")

Sandeep,

Is there anything interesting in the valgrind log file?

Thanks,
Neo

>
> Thanks,
> Sandeep
>
> Neo Jia wrote:
> > hi,
> >
> > For fun, I just ran the hotspot vm with valgrind memory checking. To
> > my surprise, valgrind has identified several "memory leak" inside vm.
> > Although there might be some false positive, I still would like to dig
> > a little bit.
> >
> > For your reference, you may get the log file from the following link
> > since it is too huge to send through a mailing list. This tiny log
> > file is generated by running helloworld.java.
> >
> > http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666
> >
> > http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666.1
> >
> >
> > Thanks,
> > Neo
>
>
>


-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!


From Sandeep.Konchady at Sun.COM  Sun May 20 23:10:42 2007
From: Sandeep.Konchady at Sun.COM (Sandeep Konchady)
Date: Sun, 20 May 2007 23:10:42 -0700
Subject: Running hotspot with valgrind to detect memory leak?
In-Reply-To: <5d649bdb0705202250j5231b367tf911e9669bb6a994@mail.gmail.com>
References: <5d649bdb0705132155n213259c0paefc17f9d660db80@mail.gmail.com>
	<465111BF.5060502@Sun.COM>
	<5d649bdb0705202250j5231b367tf911e9669bb6a994@mail.gmail.com>
Message-ID: <465137E2.8030201@Sun.COM>

Neo,

    I have not done any extensive work on Valgrind, so I am not sure how 
best to interpret the logs. That said the one interesting thing is that 
there is a leak listed in nmethod call just before it crashed. However 
the overall leak was not that significant. Let me know if you want to 
take a peek at the complete log.

==00:00:17:26.750 6946== 3,587,249 bytes in 2,672 blocks are still 
reachable in loss record 264 of 264
==00:00:17:26.750 6946==    at 0x4021620: malloc (vg_replace_malloc.c:149)
==00:00:17:26.750 6946==    by 0x6328E96: os::malloc(unsigned) (in 
/home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
==00:00:17:26.750 6946==    by 0x61A7FD8: 
CodeBlob::set_oop_maps(OopMapSet*) (in 
/home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
==00:00:17:26.750 6946==    by 0x61A87AB: CodeBlob::CodeBlob(char 
const*, CodeBuffer*, int, int, int, int, OopMapSet*) (in 
/home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
==00:00:17:26.750 6946==    by 0x631E154: 
nmethod::nmethod(methodOopDesc*, int, int, int, CodeOffsets*, int, 
DebugInformationRecorder*, Dependencies*, CodeBuffer*, int, OopMapSet*, 
ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, int) 
(in 
/home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
==00:00:17:26.751 6946==    by 0x631F115: 
nmethod::new_nmethod(methodHandle, int, int, CodeOffsets*, int, 
DebugInformationRecorder*, Dependencies*, CodeBuffer*, int, OopMapSet*, 
ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, int) 
(in 
/home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
==00:00:17:26.751 6946==    by 0x617D80E: 
ciEnv::register_method(ciMethod*, int, CodeOffsets*, int, CodeBuffer*, 
int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, 
AbstractCompiler*, int, bool, bool) (in 
/home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
==00:00:17:26.751 6946==    by 0x61021EA: Compilation::compile_method() 
(in 
/home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
==00:00:17:26.751 6946==    by 0x61023AC: 
Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int) (in 
/home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
==00:00:17:26.751 6946==    by 0x61025C7: 
Compiler::compile_method(ciEnv*, ciMethod*, int) (in 
/home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
==00:00:17:26.751 6946==    by 0x61BB195: 
CompileBroker::invoke_compiler_on_method(CompileTask*) (in 
/home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
==00:00:17:26.751 6946==    by 0x61BC246: 
CompileBroker::compiler_thread_loop() (in 
/home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
==00:00:17:26.751 6946==
==00:00:17:26.752 6946== LEAK SUMMARY:
==00:00:17:26.752 6946==    definitely lost: 15,125 bytes in 168 blocks.
==00:00:17:26.752 6946==    indirectly lost: 83,108 bytes in 2,814 blocks.
==00:00:17:26.752 6946==      possibly lost: 15,521 bytes in 33 blocks.
==00:00:17:26.752 6946==    still reachable: 4,289,428 bytes in 5,384 
blocks.
==00:00:17:26.752 6946==         suppressed: 0 bytes in 0 blocks.

Thanks,
Sandeep

Neo Jia wrote:
> On 5/20/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
>> Hi,
>>
>>     Extending what Neo Jia ran on JVM, I tested OpenJDK VM with Valgrind
>> using MemoryMonitor demo. To my surprise I got a HotSpot crash in
>> nmethod.cpp. I am attaching hs_err log file to this email and can give
>> the Valgrind log if needed. Also I was unable to find similar report on
>> SDN bug database.
>>
>> #  Internal Error (nmethod.cpp:1822), pid=6946, tid=80788368
>> #  Error: guarantee(cont_offset != 0,"unhandled implicit exception in
>> compiled code")
>
> Sandeep,
>
> Is there anything interesting in the valgrind log file?
>
> Thanks,
> Neo
>
>>
>> Thanks,
>> Sandeep
>>
>> Neo Jia wrote:
>> > hi,
>> >
>> > For fun, I just ran the hotspot vm with valgrind memory checking. To
>> > my surprise, valgrind has identified several "memory leak" inside vm.
>> > Although there might be some false positive, I still would like to dig
>> > a little bit.
>> >
>> > For your reference, you may get the log file from the following link
>> > since it is too huge to send through a mailing list. This tiny log
>> > file is generated by running helloworld.java.
>> >
>> > 
>> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666 
>>
>> >
>> > 
>> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666.1 
>>
>> >
>> >
>> > Thanks,
>> > Neo
>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070520/0db1d3bb/attachment.html 

From neojia at gmail.com  Sun May 20 23:31:16 2007
From: neojia at gmail.com (Neo Jia)
Date: Mon, 21 May 2007 01:31:16 -0500
Subject: Running hotspot with valgrind to detect memory leak?
In-Reply-To: <465137E2.8030201@Sun.COM>
References: <5d649bdb0705132155n213259c0paefc17f9d660db80@mail.gmail.com>
	<465111BF.5060502@Sun.COM>
	<5d649bdb0705202250j5231b367tf911e9669bb6a994@mail.gmail.com>
	<465137E2.8030201@Sun.COM>
Message-ID: <5d649bdb0705202331y34cdd1bck4ab4f0d0e398b617@mail.gmail.com>

On 5/21/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
>
>  Neo,
>
>      I have not done any extensive work on Valgrind, so I am not sure how
> best to interpret the logs. That said the one interesting thing is that
> there is a leak listed in nmethod call just before it crashed.

Sandeep,

Thank you for your quick responds!

I think that leak is not the root cause of this problem. See my comments below.

However the
> overall leak was not that significant. Let me know if you want to take a
> peek at the complete log.

Yes, I would like to take a look at the complete log. Due to the
mailing list limitation, posting a link should be fine.

>
>  ==00:00:17:26.750 6946== 3,587,249 bytes in 2,672 blocks are still
> reachable in loss record 264 of 264

Those "loss record" are still "reachable", which means those memory
still can be claimed by program (probably GC if it is on the GC-heap).

>  ==00:00:17:26.750 6946==    at 0x4021620: malloc (vg_replace_malloc.c:149)
>  ==00:00:17:26.750 6946==    by 0x6328E96: os::malloc(unsigned) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.750 6946==    by 0x61A7FD8:
> CodeBlob::set_oop_maps(OopMapSet*) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.750 6946==    by 0x61A87AB: CodeBlob::CodeBlob(char const*,
> CodeBuffer*, int, int, int, int, OopMapSet*) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.750 6946==    by 0x631E154:
> nmethod::nmethod(methodOopDesc*, int, int, int,
> CodeOffsets*, int, DebugInformationRecorder*, Dependencies*, CodeBuffer*,
> int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*,
> AbstractCompiler*, int) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x631F115:
> nmethod::new_nmethod(methodHandle, int, int, CodeOffsets*,
> int, DebugInformationRecorder*, Dependencies*, CodeBuffer*, int, OopMapSet*,
> ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, int) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x617D80E:
> ciEnv::register_method(ciMethod*, int, CodeOffsets*, int,
> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
> ImplicitExceptionTable*, AbstractCompiler*, int, bool, bool) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x61021EA: Compilation::compile_method() (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x61023AC:
> Compilation::Compilation(AbstractCompiler*, ciEnv*,
> ciMethod*, int) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x61025C7:
> Compiler::compile_method(ciEnv*, ciMethod*, int) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x61BB195:
> CompileBroker::invoke_compiler_on_method(CompileTask*) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x61BC246:
> CompileBroker::compiler_thread_loop() (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==
>  ==00:00:17:26.752 6946== LEAK SUMMARY:
>  ==00:00:17:26.752 6946==    definitely lost: 15,125 bytes in 168 blocks.

Actually, I am pretty interested in those "definitely lost". Will that
be a potential bug or will this show that Valgrind cannot detect
memory leak for a VM, which has its own GC?

Thanks,
Neo

>  ==00:00:17:26.752 6946==    indirectly lost: 83,108 bytes in 2,814 blocks.
>  ==00:00:17:26.752 6946==      possibly lost: 15,521 bytes in 33 blocks.
>  ==00:00:17:26.752 6946==    still reachable: 4,289,428 bytes in 5,384
> blocks.
>  ==00:00:17:26.752 6946==         suppressed: 0 bytes in 0 blocks.
>
>
>  Thanks,
>  Sandeep
>
>  Neo Jia wrote:
> On 5/20/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
>
> Hi,
>
>      Extending what Neo Jia ran on JVM, I tested OpenJDK VM with Valgrind
>  using MemoryMonitor demo. To my surprise I got a HotSpot crash in
>  nmethod.cpp. I am attaching hs_err log file to this email and can give
>  the Valgrind log if needed. Also I was unable to find similar report on
>  SDN bug database.
>
>  #  Internal Error (nmethod.cpp:1822), pid=6946, tid=80788368
>  #  Error: guarantee(cont_offset != 0,"unhandled implicit exception in
>  compiled code")
>
>  Sandeep,
>
>  Is there anything interesting in the valgrind log file?
>
>  Thanks,
>  Neo
>
>
>
>  Thanks,
>  Sandeep
>
>  Neo Jia wrote:
>  > hi,
>  >
>  > For fun, I just ran the hotspot vm with valgrind memory checking. To
>  > my surprise, valgrind has identified several "memory leak" inside vm.
>  > Although there might be some false positive, I still would like to dig
>  > a little bit.
>  >
>  > For your reference, you may get the log file from the following link
>  > since it is too huge to send through a mailing list. This tiny log
>  > file is generated by running helloworld.java.
>  >
>  >
> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666
>  >
>  >
> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666.1
>  >
>  >
>  > Thanks,
>  > Neo
>
>
>
>
>
>
>


-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!


From Steve.Goldman at Sun.COM  Mon May 21 11:20:46 2007
From: Steve.Goldman at Sun.COM (steve goldman)
Date: Mon, 21 May 2007 14:20:46 -0400
Subject: Running hotspot with valgrind to detect memory leak?
In-Reply-To: <465137E2.8030201@Sun.COM>
References: <5d649bdb0705132155n213259c0paefc17f9d660db80@mail.gmail.com>
	<465111BF.5060502@Sun.COM>
	<5d649bdb0705202250j5231b367tf911e9669bb6a994@mail.gmail.com>
	<465137E2.8030201@Sun.COM>
Message-ID: <4651E2FE.4040208@sun.com>

Sandeep Konchady wrote:
> Neo,
> 
>    I have not done any extensive work on Valgrind, so I am not sure how 
> best to interpret the logs. That said the one interesting thing is that 
> there is a leak listed in nmethod call just before it crashed. However 
> the overall leak was not that significant. Let me know if you want to 
> take a peek at the complete log.
> 
> ==00:00:17:26.750 6946== 3,587,249 bytes in 2,672 blocks are still 
> reachable in loss record 264 of 264
> ==00:00:17:26.750 6946==    at 0x4021620: malloc (vg_replace_malloc.c:149)
> ==00:00:17:26.750 6946==    by 0x6328E96: os::malloc(unsigned) (in 
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 
> 
> ==00:00:17:26.750 6946==    by 0x61A7FD8: 
> CodeBlob::set_oop_maps(OopMapSet*) (in 
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 

The humorous thing here is the comment in that piece of code:

   // Danger Will Robinson! This method allocates a big
   // chunk of memory, its your job to free it.

However the _oop_maps are freed by CodeBlob::flush() which is called by 
nmethod::flush() when we finally remove an nmethod. So I don't see the 
leak directly and unfortunately the log is only showing the allocation 
site not where it leaks. Since nmethods are coming out of the codeCache 
which isn't malloc'd memory I have to wonder if valgrind is being 
tricked here. I have no experience with valgrind so I don't know if that 
might be the case.

-- 
Steve


From dfabulich at warpmail.net  Sun May 20 22:47:40 2007
From: dfabulich at warpmail.net (Dan Fabulich)
Date: Sun, 20 May 2007 22:47:40 -0700 (Pacific Daylight Time)
Subject: Which parts of the binary blob are actually needed?
In-Reply-To: <007201c79b14$d548d5c0$802ca8c0@XPWork>
References: <007201c79b14$d548d5c0$802ca8c0@XPWork>
Message-ID: <Pine.WNT.4.63.0705202235530.3856@tbf>

Ted Neward wrote:

> Why is that? And is there someplace else one can find the t2k.dll?

The DLL *is* included in the binary plugs, but you need t2k.lib, not 
t2k.dll.  As far as I know, the .lib file is not available for download 
anywhere.

However, Dmitri suggested a workaround: it should be possible to grab the 
source code for the non-open JRL JDK 7 and build that from scratch.  That 
will generate a t2k.lib that you could use for building the OpenJDK.  I 
don't know whether that works because I don't want to contaminate the GPL 
OpenJDK with details from the JRL JDK, but someone could try it and tell 
me if it works.

It's probably best to just wait until the folks at Sun release working 
binary plugs for Windows.  However, that may not happen; instead, we may 
have to wait until the font rasterizer is fully replaced.

-Dan

>> -----Original Message-----
>> Don't forget that you can't build OpenJDK on Windows because you need
>> t2k.lib, not t2k.dll.  t2k.lib is not distributed in the Windows binary
>> plugs, so doing a build on that platform is impossible.
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6555215


From neojia at gmail.com  Mon May 21 12:32:07 2007
From: neojia at gmail.com (Neo Jia)
Date: Mon, 21 May 2007 14:32:07 -0500
Subject: Running hotspot with valgrind to detect memory leak?
In-Reply-To: <4651C656.2050204@Sun.COM>
References: <5d649bdb0705132155n213259c0paefc17f9d660db80@mail.gmail.com>
	<465111BF.5060502@Sun.COM>
	<5d649bdb0705202250j5231b367tf911e9669bb6a994@mail.gmail.com>
	<465137E2.8030201@Sun.COM>
	<5d649bdb0705202331y34cdd1bck4ab4f0d0e398b617@mail.gmail.com>
	<4651C656.2050204@Sun.COM>
Message-ID: <5d649bdb0705211232ufe7ee0y41b3a6abc036fc2a@mail.gmail.com>

On 5/21/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
> Hi Neo,
>
>     Thanks for your analysis of the logs. Unfortunately I do not have a
> means of publishing the Valgrind results in a web accessible manner. I
> am sending you the results and would really appreciate if you could
> publish the same in the location you published your results earlier. I
> will check with HotSpot folks if there is any other means of publishing
> these logs from Sun.

Sandeep,

Thanks for your log file. I just put it on my Sun Workstation :), you
may access it at
http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_memory/valgrind_java.log.

BTW, I assume that this test case will not fail if you run it without
valgrind, right?

Thanks,
Neo

>
> Thanks,
> Sandeep
>
> Neo Jia wrote:
> > On 5/21/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
> >>
> >>  Neo,
> >>
> >>      I have not done any extensive work on Valgrind, so I am not sure
> >> how
> >> best to interpret the logs. That said the one interesting thing is that
> >> there is a leak listed in nmethod call just before it crashed.
> >
> > Sandeep,
> >
> > Thank you for your quick responds!
> >
> > I think that leak is not the root cause of this problem. See my
> > comments below.
> >
> > However the
> >> overall leak was not that significant. Let me know if you want to take a
> >> peek at the complete log.
> >
> > Yes, I would like to take a look at the complete log. Due to the
> > mailing list limitation, posting a link should be fine.
> >
> >>
> >>  ==00:00:17:26.750 6946== 3,587,249 bytes in 2,672 blocks are still
> >> reachable in loss record 264 of 264
> >
> > Those "loss record" are still "reachable", which means those memory
> > still can be claimed by program (probably GC if it is on the GC-heap).
> >
> >>  ==00:00:17:26.750 6946==    at 0x4021620: malloc
> >> (vg_replace_malloc.c:149)
> >>  ==00:00:17:26.750 6946==    by 0x6328E96: os::malloc(unsigned) (in
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >>  ==00:00:17:26.750 6946==    by 0x61A7FD8:
> >> CodeBlob::set_oop_maps(OopMapSet*) (in
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >>  ==00:00:17:26.750 6946==    by 0x61A87AB: CodeBlob::CodeBlob(char
> >> const*,
> >> CodeBuffer*, int, int, int, int, OopMapSet*) (in
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >>  ==00:00:17:26.750 6946==    by 0x631E154:
> >> nmethod::nmethod(methodOopDesc*, int, int, int,
> >> CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
> >> CodeBuffer*,
> >> int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*,
> >> AbstractCompiler*, int) (in
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >>  ==00:00:17:26.751 6946==    by 0x631F115:
> >> nmethod::new_nmethod(methodHandle, int, int, CodeOffsets*,
> >> int, DebugInformationRecorder*, Dependencies*, CodeBuffer*, int,
> >> OopMapSet*,
> >> ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*,
> >> int) (in
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >>  ==00:00:17:26.751 6946==    by 0x617D80E:
> >> ciEnv::register_method(ciMethod*, int, CodeOffsets*, int,
> >> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
> >> ImplicitExceptionTable*, AbstractCompiler*, int, bool, bool) (in
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >>  ==00:00:17:26.751 6946==    by 0x61021EA:
> >> Compilation::compile_method() (in
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >>  ==00:00:17:26.751 6946==    by 0x61023AC:
> >> Compilation::Compilation(AbstractCompiler*, ciEnv*,
> >> ciMethod*, int) (in
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >>  ==00:00:17:26.751 6946==    by 0x61025C7:
> >> Compiler::compile_method(ciEnv*, ciMethod*, int) (in
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >>  ==00:00:17:26.751 6946==    by 0x61BB195:
> >> CompileBroker::invoke_compiler_on_method(CompileTask*) (in
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >>  ==00:00:17:26.751 6946==    by 0x61BC246:
> >> CompileBroker::compiler_thread_loop() (in
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >>  ==00:00:17:26.751 6946==
> >>  ==00:00:17:26.752 6946== LEAK SUMMARY:
> >>  ==00:00:17:26.752 6946==    definitely lost: 15,125 bytes in 168
> >> blocks.
> >
> > Actually, I am pretty interested in those "definitely lost". Will that
> > be a potential bug or will this show that Valgrind cannot detect
> > memory leak for a VM, which has its own GC?
> >
> > Thanks,
> > Neo
> >
> >>  ==00:00:17:26.752 6946==    indirectly lost: 83,108 bytes in 2,814
> >> blocks.
> >>  ==00:00:17:26.752 6946==      possibly lost: 15,521 bytes in 33 blocks.
> >>  ==00:00:17:26.752 6946==    still reachable: 4,289,428 bytes in 5,384
> >> blocks.
> >>  ==00:00:17:26.752 6946==         suppressed: 0 bytes in 0 blocks.
> >>
> >>
> >>  Thanks,
> >>  Sandeep
> >>
> >>  Neo Jia wrote:
> >> On 5/20/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
> >>
> >> Hi,
> >>
> >>      Extending what Neo Jia ran on JVM, I tested OpenJDK VM with
> >> Valgrind
> >>  using MemoryMonitor demo. To my surprise I got a HotSpot crash in
> >>  nmethod.cpp. I am attaching hs_err log file to this email and can give
> >>  the Valgrind log if needed. Also I was unable to find similar report on
> >>  SDN bug database.
> >>
> >>  #  Internal Error (nmethod.cpp:1822), pid=6946, tid=80788368
> >>  #  Error: guarantee(cont_offset != 0,"unhandled implicit exception in
> >>  compiled code")
> >>
> >>  Sandeep,
> >>
> >>  Is there anything interesting in the valgrind log file?
> >>
> >>  Thanks,
> >>  Neo
> >>
> >>
> >>
> >>  Thanks,
> >>  Sandeep
> >>
> >>  Neo Jia wrote:
> >>  > hi,
> >>  >
> >>  > For fun, I just ran the hotspot vm with valgrind memory checking. To
> >>  > my surprise, valgrind has identified several "memory leak" inside vm.
> >>  > Although there might be some false positive, I still would like to
> >> dig
> >>  > a little bit.
> >>  >
> >>  > For your reference, you may get the log file from the following link
> >>  > since it is too huge to send through a mailing list. This tiny log
> >>  > file is generated by running helloworld.java.
> >>  >
> >>  >
> >> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666
> >>
> >>  >
> >>  >
> >> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666.1
> >>
> >>  >
> >>  >
> >>  > Thanks,
> >>  > Neo
>
>


-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!


From Sandeep.Konchady at Sun.COM  Mon May 21 13:07:30 2007
From: Sandeep.Konchady at Sun.COM (Sandeep Konchady)
Date: Mon, 21 May 2007 13:07:30 -0700
Subject: Running hotspot with valgrind to detect memory leak?
In-Reply-To: <5d649bdb0705211232ufe7ee0y41b3a6abc036fc2a@mail.gmail.com>
References: <5d649bdb0705132155n213259c0paefc17f9d660db80@mail.gmail.com>
	<465111BF.5060502@Sun.COM>
	<5d649bdb0705202250j5231b367tf911e9669bb6a994@mail.gmail.com>
	<465137E2.8030201@Sun.COM>
	<5d649bdb0705202331y34cdd1bck4ab4f0d0e398b617@mail.gmail.com>
	<4651C656.2050204@Sun.COM>
	<5d649bdb0705211232ufe7ee0y41b3a6abc036fc2a@mail.gmail.com>
Message-ID: <4651FC02.2070504@Sun.COM>

Neo,

Thanks for publishing the log file. Yes, the MemoryMonitor demo does 
work fine if I run it without Valgrind. Somehow the combination of the 
two seems to crash the VM.

- Sandeep

Neo Jia wrote:
> On 5/21/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
>> Hi Neo,
>>
>>     Thanks for your analysis of the logs. Unfortunately I do not have a
>> means of publishing the Valgrind results in a web accessible manner. I
>> am sending you the results and would really appreciate if you could
>> publish the same in the location you published your results earlier. I
>> will check with HotSpot folks if there is any other means of publishing
>> these logs from Sun.
>
> Sandeep,
>
> Thanks for your log file. I just put it on my Sun Workstation :), you
> may access it at
> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_memory/valgrind_java.log. 
>
>
> BTW, I assume that this test case will not fail if you run it without
> valgrind, right?
>
> Thanks,
> Neo
>
>>
>> Thanks,
>> Sandeep
>>
>> Neo Jia wrote:
>> > On 5/21/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
>> >>
>> >>  Neo,
>> >>
>> >>      I have not done any extensive work on Valgrind, so I am not sure
>> >> how
>> >> best to interpret the logs. That said the one interesting thing is 
>> that
>> >> there is a leak listed in nmethod call just before it crashed.
>> >
>> > Sandeep,
>> >
>> > Thank you for your quick responds!
>> >
>> > I think that leak is not the root cause of this problem. See my
>> > comments below.
>> >
>> > However the
>> >> overall leak was not that significant. Let me know if you want to 
>> take a
>> >> peek at the complete log.
>> >
>> > Yes, I would like to take a look at the complete log. Due to the
>> > mailing list limitation, posting a link should be fine.
>> >
>> >>
>> >>  ==00:00:17:26.750 6946== 3,587,249 bytes in 2,672 blocks are still
>> >> reachable in loss record 264 of 264
>> >
>> > Those "loss record" are still "reachable", which means those memory
>> > still can be claimed by program (probably GC if it is on the GC-heap).
>> >
>> >>  ==00:00:17:26.750 6946==    at 0x4021620: malloc
>> >> (vg_replace_malloc.c:149)
>> >>  ==00:00:17:26.750 6946==    by 0x6328E96: os::malloc(unsigned) (in
>> >> 
>> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 
>>
>> >>
>> >>  ==00:00:17:26.750 6946==    by 0x61A7FD8:
>> >> CodeBlob::set_oop_maps(OopMapSet*) (in
>> >> 
>> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 
>>
>> >>
>> >>  ==00:00:17:26.750 6946==    by 0x61A87AB: CodeBlob::CodeBlob(char
>> >> const*,
>> >> CodeBuffer*, int, int, int, int, OopMapSet*) (in
>> >> 
>> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 
>>
>> >>
>> >>  ==00:00:17:26.750 6946==    by 0x631E154:
>> >> nmethod::nmethod(methodOopDesc*, int, int, int,
>> >> CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
>> >> CodeBuffer*,
>> >> int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*,
>> >> AbstractCompiler*, int) (in
>> >> 
>> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 
>>
>> >>
>> >>  ==00:00:17:26.751 6946==    by 0x631F115:
>> >> nmethod::new_nmethod(methodHandle, int, int, CodeOffsets*,
>> >> int, DebugInformationRecorder*, Dependencies*, CodeBuffer*, int,
>> >> OopMapSet*,
>> >> ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*,
>> >> int) (in
>> >> 
>> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 
>>
>> >>
>> >>  ==00:00:17:26.751 6946==    by 0x617D80E:
>> >> ciEnv::register_method(ciMethod*, int, CodeOffsets*, int,
>> >> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
>> >> ImplicitExceptionTable*, AbstractCompiler*, int, bool, bool) (in
>> >> 
>> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 
>>
>> >>
>> >>  ==00:00:17:26.751 6946==    by 0x61021EA:
>> >> Compilation::compile_method() (in
>> >> 
>> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 
>>
>> >>
>> >>  ==00:00:17:26.751 6946==    by 0x61023AC:
>> >> Compilation::Compilation(AbstractCompiler*, ciEnv*,
>> >> ciMethod*, int) (in
>> >> 
>> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 
>>
>> >>
>> >>  ==00:00:17:26.751 6946==    by 0x61025C7:
>> >> Compiler::compile_method(ciEnv*, ciMethod*, int) (in
>> >> 
>> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 
>>
>> >>
>> >>  ==00:00:17:26.751 6946==    by 0x61BB195:
>> >> CompileBroker::invoke_compiler_on_method(CompileTask*) (in
>> >> 
>> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 
>>
>> >>
>> >>  ==00:00:17:26.751 6946==    by 0x61BC246:
>> >> CompileBroker::compiler_thread_loop() (in
>> >> 
>> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so) 
>>
>> >>
>> >>  ==00:00:17:26.751 6946==
>> >>  ==00:00:17:26.752 6946== LEAK SUMMARY:
>> >>  ==00:00:17:26.752 6946==    definitely lost: 15,125 bytes in 168
>> >> blocks.
>> >
>> > Actually, I am pretty interested in those "definitely lost". Will that
>> > be a potential bug or will this show that Valgrind cannot detect
>> > memory leak for a VM, which has its own GC?
>> >
>> > Thanks,
>> > Neo
>> >
>> >>  ==00:00:17:26.752 6946==    indirectly lost: 83,108 bytes in 2,814
>> >> blocks.
>> >>  ==00:00:17:26.752 6946==      possibly lost: 15,521 bytes in 33 
>> blocks.
>> >>  ==00:00:17:26.752 6946==    still reachable: 4,289,428 bytes in 
>> 5,384
>> >> blocks.
>> >>  ==00:00:17:26.752 6946==         suppressed: 0 bytes in 0 blocks.
>> >>
>> >>
>> >>  Thanks,
>> >>  Sandeep
>> >>
>> >>  Neo Jia wrote:
>> >> On 5/20/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >>      Extending what Neo Jia ran on JVM, I tested OpenJDK VM with
>> >> Valgrind
>> >>  using MemoryMonitor demo. To my surprise I got a HotSpot crash in
>> >>  nmethod.cpp. I am attaching hs_err log file to this email and can 
>> give
>> >>  the Valgrind log if needed. Also I was unable to find similar 
>> report on
>> >>  SDN bug database.
>> >>
>> >>  #  Internal Error (nmethod.cpp:1822), pid=6946, tid=80788368
>> >>  #  Error: guarantee(cont_offset != 0,"unhandled implicit 
>> exception in
>> >>  compiled code")
>> >>
>> >>  Sandeep,
>> >>
>> >>  Is there anything interesting in the valgrind log file?
>> >>
>> >>  Thanks,
>> >>  Neo
>> >>
>> >>
>> >>
>> >>  Thanks,
>> >>  Sandeep
>> >>
>> >>  Neo Jia wrote:
>> >>  > hi,
>> >>  >
>> >>  > For fun, I just ran the hotspot vm with valgrind memory 
>> checking. To
>> >>  > my surprise, valgrind has identified several "memory leak" 
>> inside vm.
>> >>  > Although there might be some false positive, I still would like to
>> >> dig
>> >>  > a little bit.
>> >>  >
>> >>  > For your reference, you may get the log file from the following 
>> link
>> >>  > since it is too huge to send through a mailing list. This tiny log
>> >>  > file is generated by running helloworld.java.
>> >>  >
>> >>  >
>> >> 
>> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666 
>>
>> >>
>> >>  >
>> >>  >
>> >> 
>> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666.1 
>>
>> >>
>> >>  >
>> >>  >
>> >>  > Thanks,
>> >>  > Neo


From neojia at gmail.com  Mon May 21 15:27:53 2007
From: neojia at gmail.com (Neo Jia)
Date: Mon, 21 May 2007 17:27:53 -0500
Subject: Running hotspot with valgrind to detect memory leak?
In-Reply-To: <4651FC02.2070504@Sun.COM>
References: <5d649bdb0705132155n213259c0paefc17f9d660db80@mail.gmail.com>
	<465111BF.5060502@Sun.COM>
	<5d649bdb0705202250j5231b367tf911e9669bb6a994@mail.gmail.com>
	<465137E2.8030201@Sun.COM>
	<5d649bdb0705202331y34cdd1bck4ab4f0d0e398b617@mail.gmail.com>
	<4651C656.2050204@Sun.COM>
	<5d649bdb0705211232ufe7ee0y41b3a6abc036fc2a@mail.gmail.com>
	<4651FC02.2070504@Sun.COM>
Message-ID: <5d649bdb0705211527g89c8e00ne91f1dc0bee55323@mail.gmail.com>

On 5/21/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
> Neo,
>
> Thanks for publishing the log file. Yes, the MemoryMonitor demo does
> work fine if I run it without Valgrind. Somehow the combination of the
> two seems to crash the VM.

Sandeep,

I tried the valgrind (latest version 3.2.3) with the openJDK (latest
svn checkout) on my Intel IA32 machine running Fedora Core 3. Valgrind
crashes even before the application runs :(. I have to wait for Fedora
7 this Friday.

Are you using the latest version of openJDK from svn? Can you run
valgrind with "-v"?

Thanks,
Neo

>
> - Sandeep
>
> Neo Jia wrote:
> > On 5/21/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
> >> Hi Neo,
> >>
> >>     Thanks for your analysis of the logs. Unfortunately I do not have a
> >> means of publishing the Valgrind results in a web accessible manner. I
> >> am sending you the results and would really appreciate if you could
> >> publish the same in the location you published your results earlier. I
> >> will check with HotSpot folks if there is any other means of publishing
> >> these logs from Sun.
> >
> > Sandeep,
> >
> > Thanks for your log file. I just put it on my Sun Workstation :), you
> > may access it at
> > http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_memory/valgrind_java.log.
> >
> >
> > BTW, I assume that this test case will not fail if you run it without
> > valgrind, right?
> >
> > Thanks,
> > Neo
> >
> >>
> >> Thanks,
> >> Sandeep
> >>
> >> Neo Jia wrote:
> >> > On 5/21/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
> >> >>
> >> >>  Neo,
> >> >>
> >> >>      I have not done any extensive work on Valgrind, so I am not sure
> >> >> how
> >> >> best to interpret the logs. That said the one interesting thing is
> >> that
> >> >> there is a leak listed in nmethod call just before it crashed.
> >> >
> >> > Sandeep,
> >> >
> >> > Thank you for your quick responds!
> >> >
> >> > I think that leak is not the root cause of this problem. See my
> >> > comments below.
> >> >
> >> > However the
> >> >> overall leak was not that significant. Let me know if you want to
> >> take a
> >> >> peek at the complete log.
> >> >
> >> > Yes, I would like to take a look at the complete log. Due to the
> >> > mailing list limitation, posting a link should be fine.
> >> >
> >> >>
> >> >>  ==00:00:17:26.750 6946== 3,587,249 bytes in 2,672 blocks are still
> >> >> reachable in loss record 264 of 264
> >> >
> >> > Those "loss record" are still "reachable", which means those memory
> >> > still can be claimed by program (probably GC if it is on the GC-heap).
> >> >
> >> >>  ==00:00:17:26.750 6946==    at 0x4021620: malloc
> >> >> (vg_replace_malloc.c:149)
> >> >>  ==00:00:17:26.750 6946==    by 0x6328E96: os::malloc(unsigned) (in
> >> >>
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >> >>
> >> >>  ==00:00:17:26.750 6946==    by 0x61A7FD8:
> >> >> CodeBlob::set_oop_maps(OopMapSet*) (in
> >> >>
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >> >>
> >> >>  ==00:00:17:26.750 6946==    by 0x61A87AB: CodeBlob::CodeBlob(char
> >> >> const*,
> >> >> CodeBuffer*, int, int, int, int, OopMapSet*) (in
> >> >>
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >> >>
> >> >>  ==00:00:17:26.750 6946==    by 0x631E154:
> >> >> nmethod::nmethod(methodOopDesc*, int, int, int,
> >> >> CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
> >> >> CodeBuffer*,
> >> >> int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*,
> >> >> AbstractCompiler*, int) (in
> >> >>
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >> >>
> >> >>  ==00:00:17:26.751 6946==    by 0x631F115:
> >> >> nmethod::new_nmethod(methodHandle, int, int, CodeOffsets*,
> >> >> int, DebugInformationRecorder*, Dependencies*, CodeBuffer*, int,
> >> >> OopMapSet*,
> >> >> ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*,
> >> >> int) (in
> >> >>
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >> >>
> >> >>  ==00:00:17:26.751 6946==    by 0x617D80E:
> >> >> ciEnv::register_method(ciMethod*, int, CodeOffsets*, int,
> >> >> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
> >> >> ImplicitExceptionTable*, AbstractCompiler*, int, bool, bool) (in
> >> >>
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >> >>
> >> >>  ==00:00:17:26.751 6946==    by 0x61021EA:
> >> >> Compilation::compile_method() (in
> >> >>
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >> >>
> >> >>  ==00:00:17:26.751 6946==    by 0x61023AC:
> >> >> Compilation::Compilation(AbstractCompiler*, ciEnv*,
> >> >> ciMethod*, int) (in
> >> >>
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >> >>
> >> >>  ==00:00:17:26.751 6946==    by 0x61025C7:
> >> >> Compiler::compile_method(ciEnv*, ciMethod*, int) (in
> >> >>
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >> >>
> >> >>  ==00:00:17:26.751 6946==    by 0x61BB195:
> >> >> CompileBroker::invoke_compiler_on_method(CompileTask*) (in
> >> >>
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >> >>
> >> >>  ==00:00:17:26.751 6946==    by 0x61BC246:
> >> >> CompileBroker::compiler_thread_loop() (in
> >> >>
> >> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
> >>
> >> >>
> >> >>  ==00:00:17:26.751 6946==
> >> >>  ==00:00:17:26.752 6946== LEAK SUMMARY:
> >> >>  ==00:00:17:26.752 6946==    definitely lost: 15,125 bytes in 168
> >> >> blocks.
> >> >
> >> > Actually, I am pretty interested in those "definitely lost". Will that
> >> > be a potential bug or will this show that Valgrind cannot detect
> >> > memory leak for a VM, which has its own GC?
> >> >
> >> > Thanks,
> >> > Neo
> >> >
> >> >>  ==00:00:17:26.752 6946==    indirectly lost: 83,108 bytes in 2,814
> >> >> blocks.
> >> >>  ==00:00:17:26.752 6946==      possibly lost: 15,521 bytes in 33
> >> blocks.
> >> >>  ==00:00:17:26.752 6946==    still reachable: 4,289,428 bytes in
> >> 5,384
> >> >> blocks.
> >> >>  ==00:00:17:26.752 6946==         suppressed: 0 bytes in 0 blocks.
> >> >>
> >> >>
> >> >>  Thanks,
> >> >>  Sandeep
> >> >>
> >> >>  Neo Jia wrote:
> >> >> On 5/20/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >>      Extending what Neo Jia ran on JVM, I tested OpenJDK VM with
> >> >> Valgrind
> >> >>  using MemoryMonitor demo. To my surprise I got a HotSpot crash in
> >> >>  nmethod.cpp. I am attaching hs_err log file to this email and can
> >> give
> >> >>  the Valgrind log if needed. Also I was unable to find similar
> >> report on
> >> >>  SDN bug database.
> >> >>
> >> >>  #  Internal Error (nmethod.cpp:1822), pid=6946, tid=80788368
> >> >>  #  Error: guarantee(cont_offset != 0,"unhandled implicit
> >> exception in
> >> >>  compiled code")
> >> >>
> >> >>  Sandeep,
> >> >>
> >> >>  Is there anything interesting in the valgrind log file?
> >> >>
> >> >>  Thanks,
> >> >>  Neo
> >> >>
> >> >>
> >> >>
> >> >>  Thanks,
> >> >>  Sandeep
> >> >>
> >> >>  Neo Jia wrote:
> >> >>  > hi,
> >> >>  >
> >> >>  > For fun, I just ran the hotspot vm with valgrind memory
> >> checking. To
> >> >>  > my surprise, valgrind has identified several "memory leak"
> >> inside vm.
> >> >>  > Although there might be some false positive, I still would like to
> >> >> dig
> >> >>  > a little bit.
> >> >>  >
> >> >>  > For your reference, you may get the log file from the following
> >> link
> >> >>  > since it is too huge to send through a mailing list. This tiny log
> >> >>  > file is generated by running helloworld.java.
> >> >>  >
> >> >>  >
> >> >>
> >> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666
> >>
> >> >>
> >> >>  >
> >> >>  >
> >> >>
> >> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666.1
> >>
> >> >>
> >> >>  >
> >> >>  >
> >> >>  > Thanks,
> >> >>  > Neo
>


-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!


From luigi at diacronic.org  Mon May 28 08:38:42 2007
From: luigi at diacronic.org (=?iso-8859-1?Q?Luigi_De_Don=E0?=)
Date: Mon, 28 May 2007 17:38:42 +0200
Subject: Porting on mipsel/debian
Message-ID: <20070528153845.ABCCF430F@netra.tizianodinca.com>

Hi,

When will you have ready a JRE runnable on a MIPSEL/DEBIAN host ?

Many Thanks
Please let me know
Luigi



From Peter.Kessler at Sun.COM  Mon May 28 13:47:29 2007
From: Peter.Kessler at Sun.COM (Peter B. Kessler)
Date: Mon, 28 May 2007 13:47:29 -0700
Subject: Porting on mipsel/debian
In-Reply-To: <20070528153845.ABCCF430F@netra.tizianodinca.com>
References: <20070528153845.ABCCF430F@netra.tizianodinca.com>
Message-ID: <465B3FE1.3050402@Sun.COM>

Luigi De Don? wrote:
> Hi,
> 
> When will you have ready a JRE runnable on a MIPSEL/DEBIAN host ?
> 
> Many Thanks
> Please let me know
> Luigi

I'm pretty sure this would be a more appropriate question for
the distro-pkg-dev at openjdk.java.net mailing list.  It has
almost nothing to do with the HotSpot virtual machine, and
almost everything to do with packaging for a particular distro.

			... peter



From tony.printezis at sun.com  Mon May 28 13:49:27 2007
From: tony.printezis at sun.com (Tony Printezis)
Date: Mon, 28 May 2007 16:49:27 -0400 (EDT)
Subject: Porting on mipsel/debian
In-Reply-To: <465B3FE1.3050402@Sun.COM>
References: <20070528153845.ABCCF430F@netra.tizianodinca.com>
	<465B3FE1.3050402@Sun.COM>
Message-ID: <Pine.GSO.4.63.0705281647220.11787@islay>

On Mon, 28 May 2007, Peter B. Kessler wrote:

Peter,

Actually, I _think_ MIPSEL refers to little-endianess MIPS.

Luigi,

I'm personally not aware of a Hotspot port to MIPS within Sun. But, the 
source is out there so, if you're feeling brave, give it a go! :-)

Tony

> Luigi De Don? wrote:
>> Hi,
>> 
>> When will you have ready a JRE runnable on a MIPSEL/DEBIAN host ?
>> 
>> Many Thanks
>> Please let me know
>> Luigi
>
> I'm pretty sure this would be a more appropriate question for
> the distro-pkg-dev at openjdk.java.net mailing list.  It has
> almost nothing to do with the HotSpot virtual machine, and
> almost everything to do with packaging for a particular distro.
>
> 			... peter
>
>

---------------------------------------------------------------------------
| Tony Printezis, Staff Engineer, Java SE | Sun Microsystems Inc.         |
|                                         | MS BUR02-311                  |
| e-mail: tony.printezis at sun.com          | 1 Network Drive               |
| office: +1 781 442 0998 (x20998)        | Burlington, MA01803-0902, USA |
---------------------------------------------------------------------------

From luigi at diacronic.org  Tue May 29 01:11:44 2007
From: luigi at diacronic.org (=?iso-8859-1?Q?Luigi_De_Don=E0?=)
Date: Tue, 29 May 2007 10:11:44 +0200
Subject: R: Porting on mipsel/debian
In-Reply-To: <Pine.GSO.4.63.0705281647220.11787@islay>
Message-ID: <20070529081151.E51C84346@netra.tizianodinca.com>

>Actually, I _think_ MIPSEL refers to little-endianess MIPS. 
Yes, I mean that !

>I'm personally not aware of a Hotspot port to MIPS within Sun. But, the
source is out there so, if you're 
>feeling brave, give it a go! :-)
I think about GNU Classpath/GCJ, it runs on MIPS... My question is if it
possible to use the OpenJDK's runtime libraries with gcj until someone will
release a OpenJDK complete HotSpot for MIPS... It is that a difficult
effort?

Cheers
Luigi


-----Messaggio originale-----
Da: Tony Printezis [mailto:tony.printezis at sun.com] 
Inviato: luned? 28 maggio 2007 22.49
A: Peter B. Kessler
Cc: Luigi De Don?; hotspot-dev at openjdk.java.net
Oggetto: Re: Porting on mipsel/debian

On Mon, 28 May 2007, Peter B. Kessler wrote:

Peter,

Actually, I _think_ MIPSEL refers to little-endianess MIPS.

Luigi,

I'm personally not aware of a Hotspot port to MIPS within Sun. But, the
source is out there so, if you're feeling brave, give it a go! :-)

Tony

> Luigi De Don? wrote:
>> Hi,
>> 
>> When will you have ready a JRE runnable on a MIPSEL/DEBIAN host ?
>> 
>> Many Thanks
>> Please let me know
>> Luigi
>
> I'm pretty sure this would be a more appropriate question for the 
> distro-pkg-dev at openjdk.java.net mailing list.  It has almost nothing 
> to do with the HotSpot virtual machine, and almost everything to do 
> with packaging for a particular distro.
>
> 			... peter
>
>

---------------------------------------------------------------------------
| Tony Printezis, Staff Engineer, Java SE | Sun Microsystems Inc.         |
|                                         | MS BUR02-311                  |
| e-mail: tony.printezis at sun.com          | 1 Network Drive               |
| office: +1 781 442 0998 (x20998)        | Burlington, MA01803-0902, USA |
---------------------------------------------------------------------------



From gbenson at redhat.com  Thu May 31 06:14:29 2007
From: gbenson at redhat.com (Gary Benson)
Date: Thu, 31 May 2007 14:14:29 +0100
Subject: HotSpot on PPC
Message-ID: <20070531131429.GG3856@redhat.com>

Hi all,

This is just a quick introduction to say who I am and what I'm doing,
and hopefully to get in touch with people who can help or advise or
whatever.  I wasn't at FOSDEM or JavaOne so I don't really know who's
who.

So, I'm Gary, I work for Red Hat, and my job for the moment is to get
OpenJDK working on PPC.

One specific question is that a couple of people have mentioned a
portable (non-JIT) interpreter.  Can anybody tell me anything more?

Cheers,
Gary



From Bob.Vandette at Sun.COM  Thu May 31 12:57:14 2007
From: Bob.Vandette at Sun.COM (Bob Vandette)
Date: Thu, 31 May 2007 15:57:14 -0400
Subject: Hotspot on PPC
Message-ID: <465F289A.8070906@sun.com>

Hi Gary,

I should be able to answer your questions on PowerPC Hotspot and the 
portable interpreter.

PORTABLE INTERPRETER

When we did the original IA64 port of Hotspot, we decided to use a "C" 
interpreter in order to get the
port done quicker.   On architectures with many CPU registers, the "C" 
interpreter is actually just as fast or even faster
than the generated assembly version.  We use the GCC computed goto in 
order to avoid the typical dispatching
overhead of switch statements.  This interpreter is in 
hotspot/src/share/vm/interpreter/cInterpretMethod.hpp.
The problem is that the only architecture that uses the cInterpreter is 
IA64 and as far as I know,
this code isn't open sourced.  You'd need to see the glue logic that 
exists in the CPU directory to use
this interpreter.


EXISTING POWERPC PORTS

I don't know if you are aware of a Java 5 version of PowerPC that is on 
our Java SE Embedded site.
It is a hotspot implementation of Java SE 5.0 for Linux platforms.  It 
uses the Hotspot client JIT compiler and
is only 32 bit but it has passed the fully JCK certification. 


Let me know if you've got any other PPC questions.

Bob Vandette
Java Software