1. What kind of manpower would be required to perform the port?
If the platform is ok (see below), an *experienced* developer (in both Mono
and the target platform) can do it in two weeks, and then expect lots of bug
fixing in the following month[s].
If (as it seems) you are new to Mono, and
The logging profiler has support for heap snapshots (like heap-shot),
but it has never been perfect.
This mail wants to explain what's wrong, and why I think it's better
concentrating on making it work with sgen instead of insisting in trying
it with Bohem (unless we are willing to implement a
Hello!
I am running the runtime tests under the logging profiler (with various
options).
One problem I noticed is that the runtime sometimes waits for the
profiler writer thread, even if its manage callback returns false.
This makes so that some of the tests never terminates.
Another problem
This time the profiler does not touch the monitor fast path.
Apart from this it is almost identical to the previous patch.
Is it ok to commit this?
Thanks!
Massi
diff --git a/mono/metadata/monitor.c b/mono/metadata/monitor.c
index 022495a..0830645 100644
--- a/mono/metadata/monitor.c
+++
Sorry for the *late* reply... I've had problems with my mailbox
lately :-(
On Sat, 2009-01-17 at 17:11 +0100, Paul Melis wrote:
While looking at the GC statistics after a profiler run which used
--profile=logging:c I noticed the following times that seem to be the
result of
All I can add is that the logging statistical profiler needs it.
As it is in svn it does not crash anymore, but it terminates when the
main thread ends.
So, for instance, it is totally unable to profile xsp2
--nonstop (while with this patch, and using the callback, is works
fine).
Thanks!
Hello,
this patch adds hooks to profile monitor activity.
I already have a profiler that uses it, and it works (I must finish the
post processing part but the event writing and decoding works well).
I only posted the runtime portion to keep the review easier...
I know the
On Wed, 2008-09-03 at 12:23 -0400, Avery Pennarun wrote:
So my next question then is: is there any way to get mono to *not* use
threads unless you explicitly ask it to do so? It seems like just the
GC and JIT are threads right now, right? Actually I don't know enough
to even describe why
On Mon, 2008-09-08 at 16:28 +, FirstName LastName wrote:
I tried to disable the profiler but I still get the same compiler
issue. I doubled checked by looking into the config.log file
and it says that the profiler is disabled (actually, even when the
configure script finishes).
Am
On Thu, 2008-08-14 at 16:55 -0700, philly_muscle wrote:
[...]
Is there a Monodeveloper For Dummies guide for new developers who want to
join a project and how to get on a particular project such as mono-curses?
This seems a good start:
http://www.mono-project.com/Contributing
Ciao,
Massi
On Sun, 2008-08-03 at 21:57 +0200, Andreas Färber wrote:
What I will be looking into next is method-enter/method-exit probes
for tracing managed function flow, but it seems more complicated (the
JIT would need to always emit a call to a helper function, supplying
it the data to
On Tue, 2008-08-05 at 04:17 +0200, BaSS wrote:
When using mono.dll for scripting/embedding purposes, the only way to
get “scrip code” into the compiler is to use a “native” .net assembly
and move the script code into the managed world first?
AFAIK, yes.
The rationale is that Mono provides a
On Tue, 2008-08-05 at 12:26 +0200, Andreas Färber wrote:
IMO, the correct way of doing this would be to implement it in a
profiler module, and it's amazingly easy doing so.
[...]
I don't wish to replace or belittle your profiler work. I think the
two have different scopes and different
On Thu, 2008-07-31 at 01:23 +0200, Zoltan Varga wrote:
With the linear IR, most things are easy, and only a few things are
hard, like optimizations which transform multiple operations into one,
like transforming a load+operation+store into an operating taking a
memory operand on x86.
But I
I know finding a spare bit in MonoMethod is impossible :-)
On Tue, 2008-07-29 at 20:48 -0300, Rodrigo Kumpera wrote:
Other option is to kill the inline_info bit in MonoMethod and
use the space for a force_inline bit. inline_info can easily
be replaced by a hash table in mini.c. This would
On Wed, 2008-07-30 at 09:19 +0200, Kornél Pál wrote:
I believe that there is no use to force managed-to-managed wrappers to
be inlined. I just would like to elminiate the code that prevents them
being inlined. If inlining is considered carefully (this should be the
case) then I don't think
Here is the profiler todo list.
If somebody wants to suggest priorities, or propose other
features... ;-)
- Choose a name for the tool, and stick to that.
The two candidates are mprof and monoprof.
I like mprof more, but a simple google search shows that it
has been used by other minor
On Mon, 2008-07-28 at 11:23 +0100, Marek Safar wrote:
Would it be possible to show detailed string allocations? What I usually
get is something like 10 byte of string allocations but it would be
helpful to see let say top N strings.
Well, possible, yes, like everything :-)
The profiler
I think I really cannot fix the profiler init sequence without adding
another hook to the profiler API, to state that the runtime is
sufficiently initialized so that mono_thread_attach can be called
safely.
The reason is the following: I must have the profiler initialized and
the writer thread
Hello!
Rodrigo and others were asking to extend the stat profiler to recognize
also trampolines and thunks (right now they show up as unknown).
I have looked at the code, and found that the different categories of
thunks we have are, roughly:
- create_fnptr
- load_aot_method
- imt thunk
-
On Sun, 2008-07-20 at 14:43 -0300, Rodrigo Kumpera wrote:
You can change the codeman API in non breaking ways, if necessary. By
making the
current allocation function tell the profiler that these are unknown
blocks. I like this solution
as it would make changes more incremental.
True,
Hello,
I have an issue in the heap-desc functionality of the new profiler
and wanted to have some feedback on its goals before reworking it.
The issue is the following: in the logging profiler there are two
more or less separated areas that profile memory usage:
- Allocation profiling (that
On Fri, 2008-03-28 at 11:51 +0100, Paul Melis wrote:
Is the new profiler supposed to replace tools like heap-buddy and
heap-shot or is it a supplement to them?
In the long (well, even medium) term, it will replace them.
Most of the low level code is already functional.
It works this way:
Hello,
the new logging profiler is now usable on Linux, and I'd like
some feedback and bug reports.
It is described here:
http://www.mono-project.com/LoggingProfiler
and in the mono.1 man page in svn.
Open issues (for now):
- The default name of the output file should contain the
application
On Mon, 2008-02-04 at 15:22 +0100, Paolo Molaro wrote:
Did you run the corlib tests, too?
I run make check in mono, which runs just about everything,
also after a full rebuild (done with the new code).
+ // Check if this interface is explicitly implemented (instead
of just
Hello,
this is the new code, posted for review.
The reason for the rewrite is explained in the comment here:
https://bugzilla.novell.com/show_bug.cgi?id=319930
Now that monster piece of code (point [4] in the comment) is
gone, and the new code is hopefully easy to understand.
The patch still
Hello,
this is a follow up to a small brainstorming I had with Paolo.
The problem is that integrating heap-shot in the new logging
profiler is now causing deadlocks.
The logging profiler, from time to time, must write to its
output file (obviously), and these operations are protected
by a lock
On Thu, 2007-10-11 at 17:27 -0400, Chris Morgan wrote:
I'm not sure if you've ever used valgrind/kcachegrind but it might be
useful to be able to output in that format to enable easier
visualization of profiling data. As far as I know kcachegrind still
has about the best visualization for
Here is the IMT patch for an initial review.
See here for an explanation of what IMT is:
http://primates.ximian.com/~massi/blog/archive/2007/May-10.html
Initially it looked mildly unstable: when rebuilding the whole Mono
I got a couple of NRE in the mcs symbol writer while compiling some
On Sat, 2007-05-12 at 08:56 +0200, Andreas Färber wrote:
And people should read the release notes to see what's shipped,
what's supported and what's not.
This is unpractical. The Release Notes detail *changes* between
versions, not the general state of Mono for that version. Someone new
On Thu, 2007-03-01 at 21:21 -0800, Muath A. Khalaf wrote:
1- I want to ask if JIT produces code that has a frame pointer i.e.
something similar to what you get when you omit the
-fomit-frame-pointer
option with gcc.
Yes, we use the frame pointer.
2- Is it correct that: a mono single
On Sun, 2007-01-21 at 23:35 +0100, pablosantosluac wrote:
Any news related to the debugger?
We are working on it.
Mostly, changing the approach when we deal with multiple threads to
stop-resume all of them instead of let the user stop them one by
one and let the others run, completing the
Hey, you sent this on Christmas :-)
On Mon, 2006-12-25 at 19:11 +0300, Sergey Tikhonov wrote:
As we see two locals were introduced to hold sum results. In
mono_arch_allocate_vars the mono_allocate_stack_slots_full is called
to allocate locals and calculate offsets for them. Somehow it doesn't
On Thu, 2006-10-12 at 13:55 -0700, Mark E Mason wrote:
As for exporting print_ins(), if we want to do that, it needs renaming
(eg to mono_print_ins or mono_inst_print) and put into the
header file.
Where do you need it?
I'm calling it from mini-mips.c when outputting basic blocks if
On Thu, 2006-09-07 at 12:29 -0400, Miguel de Icaza wrote:
Hello,
I have some questions about mono_local_regalloc. Is it possible to tell
its logic right now not to reuse the same
physical register in the same instruction? Alpha has a lot of
registers and experience some penalty if the
As usual, I reply *late* to these interesting messages... sorry :-(
First things first: it's nice you'll do the CIL-CIL optimizer, but
there are plans to do this in the JIT anyway, where these things
belong.
I say where these things belong not to discourage you, but because
the JIT has generally
Again, first thing first: I am replying just to share knowledge,
as you said, both a CCO and an optimizing JIT have their place
in the world...
On Mon, 2006-08-14 at 19:39 +0200, Bjarke Hammersholt Roune wrote:
3. A CCO can decrease the size of an assembly by such optimizations as
dead
Sorry for the *late* reply, I was in vacation :-)
Others already explained you the while (0) thing...
On Sun, 2006-07-02 at 17:53 -0700, Rusmin Susanto wrote:
2. How do you know that sin function is equal to the following
instructions in x86:
x86_fsin (code);
x86_fldz (code);
On Mon, 2006-05-29 at 09:21 +0530, Singh, Narendra Kumar wrote:
The application is working fine when it is build with Visual;
Studio.Net 2003
But the sample application is not working on Linux in Mono
[...]
Unhandled Exception: System.DllNotFoundException: oci
IMO, the problem is that Mono
On Mon, 2006-04-10 at 13:07 -0700, Alan Cyment wrote:
Is mini.c the heart of the JIT compiler?
Well, heart is an ambiguous word here, but yes, it is the
main entry point and contains most of the core code :-)
I'm trying
to understand the way the JIT works, but I'm not
having an easy time
Working on treeprop, I noticed that sometimes the SciMark2 score
got worse, but only on amd64.
Looking at the generated code, I found that the problem was that
a variable heavily used in deep nesting BBs (level 3) was left on
the stack, while variables used at level 1 were put in registers.
So
Warning: there are still problems with this patch :-(
A full rebuild fails on an amd64 machine (while it is successful
on x86), but at this point I'm posting it anyway...
This piece of code implements a tree mover for the mono JIT IR.
To make sense of it, consider this piece of C# code:
On Tue, 2005-11-22 at 00:47 +, Mike Hearn wrote:
On Fri, 18 Nov 2005 22:36:38 +0100, Massimiliano Mantione wrote:
+#define CHECK_HEAP_STATE_LENGTH(__hssa,__bb) do {\
+ int __i = 0;\
+ MonoHssaHeapAddress *__ca =
(__hssa)-addresses_with_known_value
I see that work on the new IR will start soon...
Here is a list of things that I think it should have.
This is just from the top of my head, I didn't re-read all of the
HSSA code to see every point in which I would have liked something
more, but anyway if we'll have the infrastructure to handle
On Thu, 2005-11-17 at 13:23 +0100, Zoltan Varga wrote:
The general JIT changes in the patch look harmless to me. There is a problem
tough: the patch makes tests/marhal2.exe crash when run with -O=all.
That looks more SSAPRE than the patch (or, better, it happens if
you specify -O=ssapre and
On Tue, 2005-11-15 at 15:14 -0500, Miguel de Icaza wrote:
Hello,
The alias analysis pass has O(n) complexity (n = code size), it is
just a linear sweep on the list of instructions.
Then, deadce operates one BB at a time, scanning the code linearly
and using the liveness bits as
Hello,
this code is needed by type based alias analysis.
In this kind of analysis we need to know as precisely as possible
the class of every managed pointer that refers to an object (those
referring to value types are not relevant here).
In our IR, this kind of info is stored in the klass
On Thu, 2005-10-06 at 08:27 -0700, Harry wrote:
I have a questions regarding Mono structure
development. I have tried all the link at Mono
website, but I couldn't find it. here is my questions.
I think you are referring to the mono and mcs svn modules
(which means directories in the source
On Sat, 2005-07-23 at 00:23 -0700, Dennis Hayes wrote:
do I install the Mono that comes with Suse, or from SVN, or install
the Suse version, then up grade to the SVN version?
Ways of working are personal things (just like text editors), so...
use these advices at your own risk ;-)
Anyway, this
I have a small issue in implementing type based alias analysis.
I need to know the class of any object reference inside the code,
but this is generally unavailable in our IR.
Note that I just need to handle references to full heap objects
(pointing to a MonoObject to be clear), while managed
Inside MonoInst there are these four fields:
/* used by the register allocator */
gint32 dreg, sreg1, sreg2, unused;
As the comment says, they are used by the register allocator.
I verified it, and it seems to me that before the decompose
pass they are never touched.
For
On Wed, 2005-04-06 at 06:53 -0700, Kelly Leahy wrote:
Anyway, I think the method you describe works, but I
would recommend implementing both methods (since the
every possible path method is quite easy to
implement) so that you can do some testing to see
which actually does perform better,
On Mon, 2005-04-04 at 22:23 +0200, Zoltan Varga wrote:
with the current JIT, the liveness range of 'i' does not include the
catch block, so if i is not made volatile, the JIT might allocate 'i'
and a variable used in the catch block to the same global register,
screwing things up.
Yes, the
On Mon, 2005-04-04 at 14:28 +0200, Zoltan Varga wrote:
A simpler solution would be to mark those variables used in
catch/finally blocks as volatile.
This is already done.
Thanks for reminding me this issue (I really forgot it!).
It is a simpler approach, but it also prevents optimizations
On Tue, 2005-03-15 at 00:14, marc hoffman wrote:
It would be great if you are offering to release the source
of this Chrome compiler under an open source compatible
license.
Not likely to happen as long as some of us have to pay for rent and food
;)
Marc, there will always be
On Mon, 2005-03-07 at 21:14, Ben Maurer wrote:
Does anybody have some benchmarks where inlining was making things worse
instead of improving them?
If I remember correctly, it was making mcs bootstrap worse. It got better
when I did my hacksih inlining...
OK, I've had a look at it.
It
56 matches
Mail list logo
