Log of the #nice channel on irc.freenode.net

Using timezone: Central European Time
* ChanServ leaves00:12
* ChanServ joins00:13
* samp2p joins01:17
* samp2p leaves01:18
* arjanb leaves03:27
* arjanb joins09:51
* bonniot joins11:31
<arjanb>hi11:57
<bonniot>hi12:15
<arjanb>i have make.bat working again12:19
<bonniot>:-)12:25
could you fix the code duplications?12:26
<arjanb>i will look at that12:34
<CIA-6>03arjanb * 10Nice/src/bossa/parser/ (JavaccParser.java Parser.jj): Minor: reduced code duplication.12:40
03arjanb * 10Nice/src/ (4 files in 3 dirs): Moved nice.tools.util.Classloader to nice.tools.code.13:35
03arjanb * 10Nice/src/bossa/util/Location.java: Removed duplication in bossa.util.Location.13:45
<arjanb>why is nice/tools/util/classStripper/main.nice13:54
in cvs? it doesn't seem to be used anywhere
<bonniot>don't remember, i will look14:21
it can be used to generate a minimal version of an API, without any code, which can be useful for loading retypings14:26
it's not directly used by the compiler, but it does not hurt to have it around
<arjanb>ok14:27
* CIA-6 leaves18:17
* CIA-6 joins18:20
<bonniot>i think it might be a good idea to stop using a ClassLoader to load Java classes, but instead load them directly from our classpath19:11
<arjanb>what's the difference?19:25
<bonniot>not constructing a Class object19:33
a gnu.bytecode.ClassType can be constructed from an InputStream19:34
<arjanb>could make quite a difference depending on how much related classes and Class object needs19:39
what i see with -Xprof on the testsuite is a little classloading but much file reading19:42
<bonniot>can you show the data?19:44
<arjanb>send by mail19:50
<bonniot>do you know what stub is in hprof output?19:52
is this -Xrunhprof output? it looks very different on Linux19:54
<arjanb>-Xprof
doesn't the linux jvm have -Xprof?20:02
<bonniot>it does, and it's the same format20:07
only I knew runhprof
not sure if they mesure differently
<arjanb>-Xprof just records every 10ms which function it's executing20:08
-Xprof almost doesn't impact the performance of the jvm20:09
<bonniot>and it does not inspect the stack, unlike runhprof20:11
good to know about Xprof though20:14
the main motivation is not optimization, though20:15
(but I think it could do some, because you don't need to keep the Class object)
i thought about this when looking at the way to bext handle pathes20:16
i think we could factor more behaviour
if we don't load anything from the system classloader, we cleanly separate what is needed to run the compiler, and what is used by the source code we are compiling20:17
it should be cleaner20:18
and you could even compile against the API of a certain JDK while running on another JDK
<arjanb>i know next to nothing about classloading
<bonniot>basically, we would not do any classloading anymore :-)20:19
<arjanb>sounds good20:20
<bonniot>btw, I have quite different Xprof results:20:26
13.5% 2 + 872 java.lang.Throwable.fillInStackTrace
6.0% 14 + 376 java.lang.Object.clone
5.1% 3 + 325 java.io.FileInputStream.read
i wonder if this means that fillInStackTrace is more efficient on Windows, and IOs more efficient on Linux20:28
clone almost the same
it looks like -Xprof does not print anything if the VM exits normally20:51
can this be changed?
<arjanb>strange it does here20:52

Generated by Sualtam