Aeminium - User contributions [en]

AEminium

2013-04-19T21:58:13Z

Aeminium:

<big>'''Freeing Programmers from the Shackles of Sequentiality.'''</big>

Current programming systems shackle developers to a sequential coding paradigm.
This paradigm hampers developers from taking advantage of emerging large‐scale multicore hardware. We propose a platform which builds in concurrency by default: instead of sequencing code, programmers express dependency information, which is used by a compile‐time checker to verify correctness conditions, and by the libraries and runtime system to enable concurrent execution. As a result, developers can write parallel code in a natural style and have confidence in its correctness and performance.

Consult the [http://aeminium.dei.uc.pt/images/1/13/Aeminium_ExecutiveSummary.pdf Executive Summary] for information on the project.

<big>'''2013 International Workshop on Languages for the Multi-core Era'''</big>
July 2013, at ECOOP 2013, Montpellier, France
http://www.lirmm.fr/ec-montpellier-2013/
(also colocated with ECMFA and ECSA, and other events)

LaME provides a venue for exploring how languages and related artifacts (e.g., abstractions implemented as libraries, compilers, analysis tools, and parallel runtimes) can make parallel programming safer and more productive, without sacrificing performance. The workshop allows researchers to present new ideas, research directions, and preliminary results in an informal atmosphere that fosters discussion and feedback.

'''MORE INFORMATION AVAILABLE AT http://lame2013.dei.uc.pt'''

== AEminium at the University of Coimbra ==
AEminiumGPU [http://aeminium.dei.uc.pt/images/7/73/Alcides_fonseca_msc_thesis.pdf] is a sub-project of the AEminium project. It provides an high-level programming framework for developing parallel programs for both CPUs and GPUs. AEminiumGPU drives inspiration from Functional Programming and currently allows developers to implement programs based on the Map-Reduce pattern. In the future, the framework can be extended with other higher-order functions. AEminiumGPU does not force developers to understand the particularities of GPU programming. Programs can be written in pure Java (and soon AEminium) but specific parts of the code are compiled to OpenCL and executed on the GPU.

AEMiniumGPU is a framework composed by a compiler and a runtime. It is available for download the following address: https://github.com/alcides/AeminiumGPUCompiler/

== AEminium at the University of Madeira ==

The organizers of FMICS'11 selected the article "Multi-Task Threaded Server: A Case Study With The Plural Tool" by Néstor Cataño and Ijaz Ahmed for submission to Science of Computer Programming (SCP). FMICS invited 7 papers in total and will select 5 of them for final publication to SCP. This article discusses the business case provided by AEMinium's industrial partner Novabase.

Follow this [http://www3.uma.pt/ncatano/aeminium/Home.html link] for more information on what the University of Madeira is doing on the AEminium project.

== AEminium at the Carnegie Mellon University ==
Contact Jonathan Aldrich at CMU for more information. http://www.cs.cmu.edu/~aldrich/

== AEminium source code ==
Check out [http://code.google.com/p/aeminium/ Google Code] for code and examples (under development).

Members

2013-04-19T21:55:39Z

Aeminium: /* Other project members */

The project is a consortium of four principal investigators and one industrial partner.

'''Paulo Marques''' is an Assistant Professor at the '''University of Coimbra'''. His main research interests are concurrent systems, software reliability, and modern programming languages. He has recently led the RAIL and RAIL2 projects on code instrumentation for virtual machines, sponsored by Microsoft Research, and the LeonVM and QERL projects on dynamic code translation for the LEON2 processor, under contract with the European Space Agency. He has published extensively at international research conferences and journals and has authored two books on software development in C#.

'''Nestor Catano''' is an Assistant Professor in the Department of Mathematics and Engineering at The '''University of Madeira''', Portugal. He earned a M.Sc. and Ph.D. in Computer Science from the University of Paris 7, France. His Ph.D. was funded by the European
project Verificard (Verification of Java Card programs). He was a research associate at the University of York, U.K, from 2004 to 2006. Nestor's main research interests are the development of JML‐based tools and techniques for the verification of programs, and the mechanization of machine‐checked correctness proofs of mathematical algorithms. He has published in international research conferences on formal methods.

'''Jonathan Aldrich''' is an Assistant Professor of Computer Science at '''Carnegie Mellon University''' and Director of the Software Engineering Minor Program in the School of Computer Science. Aldrich’s research contributions include techniques for verifying object and component interaction protocols, modular reasoning techniques for aspects and stateful programs, and new object‐oriented language models. For his work on verifying software architecture, Aldrich received a 2006 NSF CAREER award and the 2007 Dahl‐Nygaard Junior Prize, the top international award for junior faculty making significant contributions to object‐oriented programming.

'''Bruno Cabral''' received his PhD in Informatics Engineering in 2009 from the University of Coimbra. He is an Assistant Professor at the '''University of Coimbra''', Portugal, and an Adjunct Associate Teaching Professor at the '''Carnegie Mellon University''', USA. His main research interests are concurrent programming and programming languages, exception handling models and code instrumentation. He has participated in many research and industrial projects in cooperation with institutions such as the European Space Agency, Microsoft Research and the Portuguese Government. He is currently leading the Institute for Software Engineering at the University of Coimbra.

Our industrial partner '''Novabase''' is one of the largest software companies in Portugal, generating
more than 140M€/year in software solutions and consulting. Novabase’s ACD (Advanced Custom Development) business unit brings a wealth of experience in developing advanced custom software solutions for its customers. Effectively leveraging the emerging class of highly parallel and multicore systems has been a significant challenge for Novabase, and the company will be an active project participant through providing motivating examples and testbeds for ensuring that Aeminium solves critical real‐world problems.

== Other project members ==

'''Sven Stork''' - Ph.D. student on the join doctoral program between CMU and the University of Coimbra

'''Filipe Militão''' - Ph.D. student on the join doctoral program between CMU and Nova University of Lisbon

'''Alcides Fonseca''' - Ph.D. student at the University of Coimbra

'''Ijaz Ahmed''' - Ph.D. student at the University of Madeira.

'''Josh Sunshine''' - PhD student at Carnegie Mellon University

'''Karl Naden''' - Ph.D. student at Carnegie Mellon University

'''Ligia Nistor''' - Ph.D. student at Carnegie Mellon University

'''Roger Wolf''' - Ph.D. student at Carnegie Mellon University

'''João Rafael''' - M.Sc. student at the University of Coimbra

'''Cristiano Gonçalves''' - M.Sc. student at the University of Coimbra

'''Pedro Costa''' - M.Sc. student at the University of Coimbra

'''Marcelo Sousa''' - Researcher at the University of Coimbra

'''Sukriti Bhattacharya''' - Post-doc at the University of Madeira

'''Rob Bocchino''' - Post-doc at Carnegie Mellon University

'''Hannes Mehnert''' - Ph.D. student visitor at CMU

'''Iain McGinniss''' - Ph.D. student visitor at CMU

== Past project members ==

'''Ivo Correia''' - M.Sc. student at the University of Coimbra

'''Manuel Mohr''' - M.Sc. student at the Karlsruhe university

'''João Barbosa''' - B.Sc. student at the University of Coimbra

'''Duarte Abreu''' - M.Sc. student at the University of Madeira

'''Alican Turk''' - B.Sc. student at Carnegie mellon University

'''Mark Hahnenberg''' - B.Sc. student at Carnegie mellon University

'''Matthew Rodriguez''' - B.Sc. student at Carnegie mellon University

== External Collaborators ==

'''Radu Siminiceanu''' - National Institute of Aerospace, NIA, USA

'''Camilo Rueda, Carlos Olarte, Gerardo Sarria''' - Pontificia Universidad Javeriana, PUJ, Cali, Colombia

'''Elaine Pimentel''' - Universidade Federal de Minas Gerais, UFMG, Brazil

Members

2013-04-19T21:54:59Z

Aeminium: /* Past project members */

The project is a consortium of four principal investigators and one industrial partner.

'''Paulo Marques''' is an Assistant Professor at the '''University of Coimbra'''. His main research interests are concurrent systems, software reliability, and modern programming languages. He has recently led the RAIL and RAIL2 projects on code instrumentation for virtual machines, sponsored by Microsoft Research, and the LeonVM and QERL projects on dynamic code translation for the LEON2 processor, under contract with the European Space Agency. He has published extensively at international research conferences and journals and has authored two books on software development in C#.

'''Nestor Catano''' is an Assistant Professor in the Department of Mathematics and Engineering at The '''University of Madeira''', Portugal. He earned a M.Sc. and Ph.D. in Computer Science from the University of Paris 7, France. His Ph.D. was funded by the European
project Verificard (Verification of Java Card programs). He was a research associate at the University of York, U.K, from 2004 to 2006. Nestor's main research interests are the development of JML‐based tools and techniques for the verification of programs, and the mechanization of machine‐checked correctness proofs of mathematical algorithms. He has published in international research conferences on formal methods.

'''Jonathan Aldrich''' is an Assistant Professor of Computer Science at '''Carnegie Mellon University''' and Director of the Software Engineering Minor Program in the School of Computer Science. Aldrich’s research contributions include techniques for verifying object and component interaction protocols, modular reasoning techniques for aspects and stateful programs, and new object‐oriented language models. For his work on verifying software architecture, Aldrich received a 2006 NSF CAREER award and the 2007 Dahl‐Nygaard Junior Prize, the top international award for junior faculty making significant contributions to object‐oriented programming.

'''Bruno Cabral''' received his PhD in Informatics Engineering in 2009 from the University of Coimbra. He is an Assistant Professor at the '''University of Coimbra''', Portugal, and an Adjunct Associate Teaching Professor at the '''Carnegie Mellon University''', USA. His main research interests are concurrent programming and programming languages, exception handling models and code instrumentation. He has participated in many research and industrial projects in cooperation with institutions such as the European Space Agency, Microsoft Research and the Portuguese Government. He is currently leading the Institute for Software Engineering at the University of Coimbra.

Our industrial partner '''Novabase''' is one of the largest software companies in Portugal, generating
more than 140M€/year in software solutions and consulting. Novabase’s ACD (Advanced Custom Development) business unit brings a wealth of experience in developing advanced custom software solutions for its customers. Effectively leveraging the emerging class of highly parallel and multicore systems has been a significant challenge for Novabase, and the company will be an active project participant through providing motivating examples and testbeds for ensuring that Aeminium solves critical real‐world problems.

== Other project members ==

'''Sven Stork''' - Ph.D. student on the join doctoral program between CMU and the University of Coimbra

'''Filipe Militão''' - Ph.D. student on the join doctoral program between CMU and Nova University of Lisbon

'''Alcides Fonseca''' - Ph.D. student at the University of Coimbra

'''Ijaz Ahmed''' - Ph.D. student at the University of Madeira.

'''Josh Sunshine''' - PhD student at Carnegie Mellon University

'''Karl Naden''' - Ph.D. student at Carnegie Mellon University

'''Ligia Nistor''' - Ph.D. student at Carnegie Mellon University

'''Roger Wolf''' - Ph.D. student at Carnegie Mellon University

'''João Rafael''' - M.Sc. student at the University of Coimbra

'''Cristiano Gonçalves''' - M.Sc. student at the University of Coimbra

'''Sukriti Bhattacharya''' - Post-doc at the University of Madeira

'''Rob Bocchino''' - Post-doc at Carnegie Mellon University

'''Hannes Mehnert''' - Ph.D. student visitor at CMU

'''Iain McGinniss''' - Ph.D. student visitor at CMU

== Past project members ==

'''Ivo Correia''' - M.Sc. student at the University of Coimbra

'''Manuel Mohr''' - M.Sc. student at the Karlsruhe university

'''João Barbosa''' - B.Sc. student at the University of Coimbra

'''Duarte Abreu''' - M.Sc. student at the University of Madeira

'''Alican Turk''' - B.Sc. student at Carnegie mellon University

'''Mark Hahnenberg''' - B.Sc. student at Carnegie mellon University

'''Matthew Rodriguez''' - B.Sc. student at Carnegie mellon University

== External Collaborators ==

'''Radu Siminiceanu''' - National Institute of Aerospace, NIA, USA

'''Camilo Rueda, Carlos Olarte, Gerardo Sarria''' - Pontificia Universidad Javeriana, PUJ, Cali, Colombia

'''Elaine Pimentel''' - Universidade Federal de Minas Gerais, UFMG, Brazil

Members

2013-04-19T21:54:48Z

Aeminium: /* Other project members */

The project is a consortium of four principal investigators and one industrial partner.

'''Paulo Marques''' is an Assistant Professor at the '''University of Coimbra'''. His main research interests are concurrent systems, software reliability, and modern programming languages. He has recently led the RAIL and RAIL2 projects on code instrumentation for virtual machines, sponsored by Microsoft Research, and the LeonVM and QERL projects on dynamic code translation for the LEON2 processor, under contract with the European Space Agency. He has published extensively at international research conferences and journals and has authored two books on software development in C#.

'''Nestor Catano''' is an Assistant Professor in the Department of Mathematics and Engineering at The '''University of Madeira''', Portugal. He earned a M.Sc. and Ph.D. in Computer Science from the University of Paris 7, France. His Ph.D. was funded by the European
project Verificard (Verification of Java Card programs). He was a research associate at the University of York, U.K, from 2004 to 2006. Nestor's main research interests are the development of JML‐based tools and techniques for the verification of programs, and the mechanization of machine‐checked correctness proofs of mathematical algorithms. He has published in international research conferences on formal methods.

'''Jonathan Aldrich''' is an Assistant Professor of Computer Science at '''Carnegie Mellon University''' and Director of the Software Engineering Minor Program in the School of Computer Science. Aldrich’s research contributions include techniques for verifying object and component interaction protocols, modular reasoning techniques for aspects and stateful programs, and new object‐oriented language models. For his work on verifying software architecture, Aldrich received a 2006 NSF CAREER award and the 2007 Dahl‐Nygaard Junior Prize, the top international award for junior faculty making significant contributions to object‐oriented programming.

'''Bruno Cabral''' received his PhD in Informatics Engineering in 2009 from the University of Coimbra. He is an Assistant Professor at the '''University of Coimbra''', Portugal, and an Adjunct Associate Teaching Professor at the '''Carnegie Mellon University''', USA. His main research interests are concurrent programming and programming languages, exception handling models and code instrumentation. He has participated in many research and industrial projects in cooperation with institutions such as the European Space Agency, Microsoft Research and the Portuguese Government. He is currently leading the Institute for Software Engineering at the University of Coimbra.

Our industrial partner '''Novabase''' is one of the largest software companies in Portugal, generating
more than 140M€/year in software solutions and consulting. Novabase’s ACD (Advanced Custom Development) business unit brings a wealth of experience in developing advanced custom software solutions for its customers. Effectively leveraging the emerging class of highly parallel and multicore systems has been a significant challenge for Novabase, and the company will be an active project participant through providing motivating examples and testbeds for ensuring that Aeminium solves critical real‐world problems.

== Other project members ==

'''Sven Stork''' - Ph.D. student on the join doctoral program between CMU and the University of Coimbra

'''Filipe Militão''' - Ph.D. student on the join doctoral program between CMU and Nova University of Lisbon

'''Alcides Fonseca''' - Ph.D. student at the University of Coimbra

'''Ijaz Ahmed''' - Ph.D. student at the University of Madeira.

'''Josh Sunshine''' - PhD student at Carnegie Mellon University

'''Karl Naden''' - Ph.D. student at Carnegie Mellon University

'''Ligia Nistor''' - Ph.D. student at Carnegie Mellon University

'''Roger Wolf''' - Ph.D. student at Carnegie Mellon University

'''João Rafael''' - M.Sc. student at the University of Coimbra

'''Cristiano Gonçalves''' - M.Sc. student at the University of Coimbra

'''Sukriti Bhattacharya''' - Post-doc at the University of Madeira

'''Rob Bocchino''' - Post-doc at Carnegie Mellon University

'''Hannes Mehnert''' - Ph.D. student visitor at CMU

'''Iain McGinniss''' - Ph.D. student visitor at CMU

== Past project members ==

'''Manuel Mohr''' - M.Sc. student at the Karlsruhe university

'''João Barbosa''' - B.Sc. student at the University of Coimbra

'''Duarte Abreu''' - M.Sc. student at the University of Madeira

'''Alican Turk''' - B.Sc. student at Carnegie mellon University

'''Mark Hahnenberg''' - B.Sc. student at Carnegie mellon University

'''Matthew Rodriguez''' - B.Sc. student at Carnegie mellon University

== External Collaborators ==

'''Radu Siminiceanu''' - National Institute of Aerospace, NIA, USA

'''Camilo Rueda, Carlos Olarte, Gerardo Sarria''' - Pontificia Universidad Javeriana, PUJ, Cali, Colombia

'''Elaine Pimentel''' - Universidade Federal de Minas Gerais, UFMG, Brazil

Events

2013-04-19T21:53:24Z

Aeminium: /* Past Events */

== <big>'''2013 International Workshop on Languages for the Multi-core Era'''</big> ==
July 2013, at ECOOP 2013, Montpellier, France
http://www.lirmm.fr/ec-montpellier-2013/
(also colocated with ECMFA and ECSA, and other events)

LaME provides a venue for exploring how languages and related artifacts (e.g., abstractions implemented as libraries, compilers, analysis tools, and parallel runtimes) can make parallel programming safer and more productive, without sacrificing performance. The workshop allows researchers to present new ideas, research directions, and preliminary results in an informal atmosphere that fosters discussion and feedback.

'''MORE INFORMATION AVAILABLE AT http://lame2013.dei.uc.pt'''

==Past Events==

<big>'''2012 International Workshop on Languages for the Multi-core Era'''</big>
June 13 2012, at ECOOP 2012, Beijing China
http://ecoop12.cs.purdue.edu/
(also colocated with PLDI, ISMM, LCTES, the X10 workshop, and other events)

LaME is an interactive venue for exposing, evaluating, and developing programming language support for concurrency. This workshop provides a forum for the proposal and discussion of creative ideas that spur the development of innovative or improved concurrency models, languages, run-time systems, libraries and tools for multicore programming.

'''MORE INFORMATION AVAILABLE AT http://http://lame.dei.uc.pt'''

<big>'''2011 Aeminium-Interfaces Joint Workshop, November 9th'''</big>

"Reitoria da Universidade Nova" in the room "Sala do Senado". http://www.unl.pt/onde-estamos/mapa/reitoria

'''Program'''

10:00 am - Welcome and Workshop Introduction

Session 1: Language-based Safety and Security for the Web

10:15 am - João Seco, Data Security with Refinement Types

10:45 am - Luís Caires, Interface Certification for Software Services

11:15 am - Antonio Melo (OutSystems), Validation Issues in web applications.

11:45 am - Discussion

12:00 am - Lunch

Session 2: Enabling Parallelism for the Masses

1:30 pm - Sven Stork, Aeminium language

2:00 pm - Alcides Fonseca, AEminiumGPU: A CPU-GPU Hybrid Runtime for the Æminium Language

2:30 pm - Filipe Martins (Novabase) - TBD

3:00 pm - Discussion

3:15 pm - Break

Session 3: Type-based Static Analysis

3:45 pm - Ijaz Ahmed (UMA) - Automated Verification of Specifications with

Typestates and Access Permissions

4:15 pm - Vasco Vasconcelos, Checking Dynamic Roles in Multiparty Communication

4:45 pm - Discussion and Wrapup

5:15 pm - Informal follow-up

<big>'''2010 Workshop on Facilitating Adoption of Parallel Computing'''</big>

'''Date''': Wednesday, '''May 5, 2010'''

'''Location''': GHC 7501 at CMU

'''Sponsor''': CMU|Portugal Program

With the rise of multicore processors and the increasing richness of application functionality, leveraging parallel computation is increasingly necessary to achieve good performance. However, parallel computing is also difficult for programmers, due to the need to decompose the problem into sub-parts which can be solved in parallel, and due to the challenges of managing potential interference between concurrent tasks.

This workshop focuses on research approaches intended to facilitate the practical adoption of parallel computing. These may include engineering approaches, new models of parallel computing, approaches for verification and reasoning in the presence of concurrency, and approaches for teaching parallel computing.

'''Schedule'''

9:00 Welcome and Workshop Introduction

9:15 Engineering Parallelism: What Works in Practice

10:15 Break

10:30 New Programming Models Facilitating Adoption of Parallelism

12:00 Lunch (provided for workshop participants)

1:00 Verification: Helping Developers Reason about Concurrency

2:00 Hardware Factors in Parallel Computing

2:45 Break

3:00 Teaching Parallel Computing

3:30 Wrapup

4:00 Informal Follow-up

Events

2013-04-19T21:52:55Z

Aeminium: /* Past Events */

== <big>'''2013 International Workshop on Languages for the Multi-core Era'''</big> ==
July 2013, at ECOOP 2013, Montpellier, France
http://www.lirmm.fr/ec-montpellier-2013/
(also colocated with ECMFA and ECSA, and other events)

LaME provides a venue for exploring how languages and related artifacts (e.g., abstractions implemented as libraries, compilers, analysis tools, and parallel runtimes) can make parallel programming safer and more productive, without sacrificing performance. The workshop allows researchers to present new ideas, research directions, and preliminary results in an informal atmosphere that fosters discussion and feedback.

'''MORE INFORMATION AVAILABLE AT http://lame2013.dei.uc.pt'''

==Past Events==

<big>'''2012 International Workshop on Languages for the Multi-core Era'''</big>
June 13 2012, at ECOOP 2012, Beijing China
http://ecoop12.cs.purdue.edu/
(also colocated with PLDI, ISMM, LCTES, the X10 workshop, and other events)

LaME is an interactive venue for exposing, evaluating, and developing programming language support for concurrency. This workshop provides a forum for the proposal and discussion of creative ideas that spur the development of innovative or improved concurrency models, languages, run-time systems, libraries and tools for multicore programming.

'''MORE INFORMATION AVAILABLE AT http://http://lame.dei.uc.pt'''

<big>'''2011 Aeminium-Interfaces Joint Workshop, November 9th''</big>'

"Reitoria da Universidade Nova" in the room "Sala do Senado". http://www.unl.pt/onde-estamos/mapa/reitoria

'''Program'''

10:00 am - Welcome and Workshop Introduction

Session 1: Language-based Safety and Security for the Web

10:15 am - João Seco, Data Security with Refinement Types

10:45 am - Luís Caires, Interface Certification for Software Services

11:15 am - Antonio Melo (OutSystems), Validation Issues in web applications.

11:45 am - Discussion

12:00 am - Lunch

Session 2: Enabling Parallelism for the Masses

1:30 pm - Sven Stork, Aeminium language

2:00 pm - Alcides Fonseca, AEminiumGPU: A CPU-GPU Hybrid Runtime for the Æminium Language

2:30 pm - Filipe Martins (Novabase) - TBD

3:00 pm - Discussion

3:15 pm - Break

Session 3: Type-based Static Analysis

3:45 pm - Ijaz Ahmed (UMA) - Automated Verification of Specifications with

Typestates and Access Permissions

4:15 pm - Vasco Vasconcelos, Checking Dynamic Roles in Multiparty Communication

4:45 pm - Discussion and Wrapup

5:15 pm - Informal follow-up

<big>'''2010 Workshop on Facilitating Adoption of Parallel Computing'''</big>

'''Date''': Wednesday, '''May 5, 2010'''

'''Location''': GHC 7501 at CMU

'''Sponsor''': CMU|Portugal Program

With the rise of multicore processors and the increasing richness of application functionality, leveraging parallel computation is increasingly necessary to achieve good performance. However, parallel computing is also difficult for programmers, due to the need to decompose the problem into sub-parts which can be solved in parallel, and due to the challenges of managing potential interference between concurrent tasks.

This workshop focuses on research approaches intended to facilitate the practical adoption of parallel computing. These may include engineering approaches, new models of parallel computing, approaches for verification and reasoning in the presence of concurrency, and approaches for teaching parallel computing.

'''Schedule'''

9:00 Welcome and Workshop Introduction

9:15 Engineering Parallelism: What Works in Practice

10:15 Break

10:30 New Programming Models Facilitating Adoption of Parallelism

12:00 Lunch (provided for workshop participants)

1:00 Verification: Helping Developers Reason about Concurrency

2:00 Hardware Factors in Parallel Computing

2:45 Break

3:00 Teaching Parallel Computing

3:30 Wrapup

4:00 Informal Follow-up

Events

2013-04-19T21:51:46Z

Aeminium: /* Past Events */

== <big>'''2013 International Workshop on Languages for the Multi-core Era'''</big> ==
July 2013, at ECOOP 2013, Montpellier, France
http://www.lirmm.fr/ec-montpellier-2013/
(also colocated with ECMFA and ECSA, and other events)

LaME provides a venue for exploring how languages and related artifacts (e.g., abstractions implemented as libraries, compilers, analysis tools, and parallel runtimes) can make parallel programming safer and more productive, without sacrificing performance. The workshop allows researchers to present new ideas, research directions, and preliminary results in an informal atmosphere that fosters discussion and feedback.

'''MORE INFORMATION AVAILABLE AT http://lame2013.dei.uc.pt'''

==Past Events==

<big>'''2012 International Workshop on Languages for the Multi-core Era'''</big>
June 13 2012, at ECOOP 2012, Beijing China
http://ecoop12.cs.purdue.edu/
(also colocated with PLDI, ISMM, LCTES, the X10 workshop, and other events)

LaME is an interactive venue for exposing, evaluating, and developing programming language support for concurrency. This workshop provides a forum for the proposal and discussion of creative ideas that spur the development of innovative or improved concurrency models, languages, run-time systems, libraries and tools for multicore programming.

'''MORE INFORMATION AVAILABLE AT http://http://lame.dei.uc.pt'''

'''Aeminium-Interfaces Joint Workshop, November 9th 2011'''

"Reitoria da Universidade Nova" in the room "Sala do Senado". http://www.unl.pt/onde-estamos/mapa/reitoria

'''Program'''

10:00 am - Welcome and Workshop Introduction

Session 1: Language-based Safety and Security for the Web

10:15 am - João Seco, Data Security with Refinement Types

10:45 am - Luís Caires, Interface Certification for Software Services

11:15 am - Antonio Melo (OutSystems), Validation Issues in web applications.

11:45 am - Discussion

12:00 am - Lunch

Session 2: Enabling Parallelism for the Masses

1:30 pm - Sven Stork, Aeminium language

2:00 pm - Alcides Fonseca, AEminiumGPU: A CPU-GPU Hybrid Runtime for the Æminium Language

2:30 pm - Filipe Martins (Novabase) - TBD

3:00 pm - Discussion

3:15 pm - Break

Session 3: Type-based Static Analysis

3:45 pm - Ijaz Ahmed (UMA) - Automated Verification of Specifications with

Typestates and Access Permissions

4:15 pm - Vasco Vasconcelos, Checking Dynamic Roles in Multiparty Communication

4:45 pm - Discussion and Wrapup

5:15 pm - Informal follow-up

'''Workshop on Facilitating Adoption of Parallel Computing'''

'''Date''': Wednesday, '''May 5, 2010'''

'''Location''': GHC 7501 at CMU

'''Sponsor''': CMU|Portugal Program

With the rise of multicore processors and the increasing richness of application functionality, leveraging parallel computation is increasingly necessary to achieve good performance. However, parallel computing is also difficult for programmers, due to the need to decompose the problem into sub-parts which can be solved in parallel, and due to the challenges of managing potential interference between concurrent tasks.

This workshop focuses on research approaches intended to facilitate the practical adoption of parallel computing. These may include engineering approaches, new models of parallel computing, approaches for verification and reasoning in the presence of concurrency, and approaches for teaching parallel computing.

'''Schedule'''

9:00 Welcome and Workshop Introduction

9:15 Engineering Parallelism: What Works in Practice

10:15 Break

10:30 New Programming Models Facilitating Adoption of Parallelism

12:00 Lunch (provided for workshop participants)

1:00 Verification: Helping Developers Reason about Concurrency

2:00 Hardware Factors in Parallel Computing

2:45 Break

3:00 Teaching Parallel Computing

3:30 Wrapup

4:00 Informal Follow-up

Events

2013-04-19T21:51:18Z

Aeminium: /* 2012 International Workshop on Languages for the Multi-core Era */

== <big>'''2013 International Workshop on Languages for the Multi-core Era'''</big> ==
July 2013, at ECOOP 2013, Montpellier, France
http://www.lirmm.fr/ec-montpellier-2013/
(also colocated with ECMFA and ECSA, and other events)

LaME provides a venue for exploring how languages and related artifacts (e.g., abstractions implemented as libraries, compilers, analysis tools, and parallel runtimes) can make parallel programming safer and more productive, without sacrificing performance. The workshop allows researchers to present new ideas, research directions, and preliminary results in an informal atmosphere that fosters discussion and feedback.

'''MORE INFORMATION AVAILABLE AT http://lame2013.dei.uc.pt'''

==Past Events==

'''Aeminium-Interfaces Joint Workshop, November 9th 2011'''

"Reitoria da Universidade Nova" in the room "Sala do Senado". http://www.unl.pt/onde-estamos/mapa/reitoria

'''Program'''

10:00 am - Welcome and Workshop Introduction

Session 1: Language-based Safety and Security for the Web

10:15 am - João Seco, Data Security with Refinement Types

10:45 am - Luís Caires, Interface Certification for Software Services

11:15 am - Antonio Melo (OutSystems), Validation Issues in web applications.

11:45 am - Discussion

12:00 am - Lunch

Session 2: Enabling Parallelism for the Masses

1:30 pm - Sven Stork, Aeminium language

2:00 pm - Alcides Fonseca, AEminiumGPU: A CPU-GPU Hybrid Runtime for the Æminium Language

2:30 pm - Filipe Martins (Novabase) - TBD

3:00 pm - Discussion

3:15 pm - Break

Session 3: Type-based Static Analysis

3:45 pm - Ijaz Ahmed (UMA) - Automated Verification of Specifications with

Typestates and Access Permissions

4:15 pm - Vasco Vasconcelos, Checking Dynamic Roles in Multiparty Communication

4:45 pm - Discussion and Wrapup

5:15 pm - Informal follow-up

'''Workshop on Facilitating Adoption of Parallel Computing'''

'''Date''': Wednesday, '''May 5, 2010'''

'''Location''': GHC 7501 at CMU

'''Sponsor''': CMU|Portugal Program

With the rise of multicore processors and the increasing richness of application functionality, leveraging parallel computation is increasingly necessary to achieve good performance. However, parallel computing is also difficult for programmers, due to the need to decompose the problem into sub-parts which can be solved in parallel, and due to the challenges of managing potential interference between concurrent tasks.

This workshop focuses on research approaches intended to facilitate the practical adoption of parallel computing. These may include engineering approaches, new models of parallel computing, approaches for verification and reasoning in the presence of concurrency, and approaches for teaching parallel computing.

'''Schedule'''

9:00 Welcome and Workshop Introduction

9:15 Engineering Parallelism: What Works in Practice

10:15 Break

10:30 New Programming Models Facilitating Adoption of Parallelism

12:00 Lunch (provided for workshop participants)

1:00 Verification: Helping Developers Reason about Concurrency

2:00 Hardware Factors in Parallel Computing

2:45 Break

3:00 Teaching Parallel Computing

3:30 Wrapup

4:00 Informal Follow-up

Events

2013-04-19T21:50:52Z

Aeminium: /* 2013 International Workshop on Languages for the Multi-core Era */

== <big>'''2013 International Workshop on Languages for the Multi-core Era'''</big> ==
July 2013, at ECOOP 2013, Montpellier, France
http://www.lirmm.fr/ec-montpellier-2013/
(also colocated with ECMFA and ECSA, and other events)

LaME provides a venue for exploring how languages and related artifacts (e.g., abstractions implemented as libraries, compilers, analysis tools, and parallel runtimes) can make parallel programming safer and more productive, without sacrificing performance. The workshop allows researchers to present new ideas, research directions, and preliminary results in an informal atmosphere that fosters discussion and feedback.

'''MORE INFORMATION AVAILABLE AT http://lame2013.dei.uc.pt'''

== <big>'''2012 International Workshop on Languages for the Multi-core Era'''</big> ==
June 13 2012, at ECOOP 2012, Beijing China
http://ecoop12.cs.purdue.edu/
(also colocated with PLDI, ISMM, LCTES, the X10 workshop, and other events)

LaME is an interactive venue for exposing, evaluating, and developing programming language support for concurrency. This workshop provides a forum for the proposal and discussion of creative ideas that spur the development of innovative or improved concurrency models, languages, run-time systems, libraries and tools for multicore programming.

'''MORE INFORMATION AVAILABLE AT http://http://lame.dei.uc.pt'''

==Past Events==

'''Aeminium-Interfaces Joint Workshop, November 9th 2011'''

"Reitoria da Universidade Nova" in the room "Sala do Senado". http://www.unl.pt/onde-estamos/mapa/reitoria

'''Program'''

10:00 am - Welcome and Workshop Introduction

Session 1: Language-based Safety and Security for the Web

10:15 am - João Seco, Data Security with Refinement Types

10:45 am - Luís Caires, Interface Certification for Software Services

11:15 am - Antonio Melo (OutSystems), Validation Issues in web applications.

11:45 am - Discussion

12:00 am - Lunch

Session 2: Enabling Parallelism for the Masses

1:30 pm - Sven Stork, Aeminium language

2:00 pm - Alcides Fonseca, AEminiumGPU: A CPU-GPU Hybrid Runtime for the Æminium Language

2:30 pm - Filipe Martins (Novabase) - TBD

3:00 pm - Discussion

3:15 pm - Break

Session 3: Type-based Static Analysis

3:45 pm - Ijaz Ahmed (UMA) - Automated Verification of Specifications with

Typestates and Access Permissions

4:15 pm - Vasco Vasconcelos, Checking Dynamic Roles in Multiparty Communication

4:45 pm - Discussion and Wrapup

5:15 pm - Informal follow-up

'''Workshop on Facilitating Adoption of Parallel Computing'''

'''Date''': Wednesday, '''May 5, 2010'''

'''Location''': GHC 7501 at CMU

'''Sponsor''': CMU|Portugal Program

With the rise of multicore processors and the increasing richness of application functionality, leveraging parallel computation is increasingly necessary to achieve good performance. However, parallel computing is also difficult for programmers, due to the need to decompose the problem into sub-parts which can be solved in parallel, and due to the challenges of managing potential interference between concurrent tasks.

This workshop focuses on research approaches intended to facilitate the practical adoption of parallel computing. These may include engineering approaches, new models of parallel computing, approaches for verification and reasoning in the presence of concurrency, and approaches for teaching parallel computing.

'''Schedule'''

9:00 Welcome and Workshop Introduction

9:15 Engineering Parallelism: What Works in Practice

10:15 Break

10:30 New Programming Models Facilitating Adoption of Parallelism

12:00 Lunch (provided for workshop participants)

1:00 Verification: Helping Developers Reason about Concurrency

2:00 Hardware Factors in Parallel Computing

2:45 Break

3:00 Teaching Parallel Computing

3:30 Wrapup

4:00 Informal Follow-up

Events

2013-04-19T21:50:32Z

Aeminium: /* 2013 International Workshop on Languages for the Multi-core Era */

== <big>'''2013 International Workshop on Languages for the Multi-core Era'''</big> ==
July 2013, at ECOOP 2013, Montpellier, France
http://www.lirmm.fr/ec-montpellier-2013/
(also colocated with ECMFA and ECSA, and other events)

LaME provides a venue for exploring how languages and related artifacts (e.g., abstractions implemented as libraries, compilers, analysis tools, and parallel runtimes) can make parallel programming safer and more productive, without sacrificing performance. The workshop allows researchers to present new ideas, research directions, and preliminary results in an informal atmosphere that fosters discussion and feedback.

'''MORE INFORMATION AVAILABLE AT http://http://lame2013.dei.uc.pt'''

== <big>'''2012 International Workshop on Languages for the Multi-core Era'''</big> ==
June 13 2012, at ECOOP 2012, Beijing China
http://ecoop12.cs.purdue.edu/
(also colocated with PLDI, ISMM, LCTES, the X10 workshop, and other events)

LaME is an interactive venue for exposing, evaluating, and developing programming language support for concurrency. This workshop provides a forum for the proposal and discussion of creative ideas that spur the development of innovative or improved concurrency models, languages, run-time systems, libraries and tools for multicore programming.

'''MORE INFORMATION AVAILABLE AT http://http://lame.dei.uc.pt'''

==Past Events==

'''Aeminium-Interfaces Joint Workshop, November 9th 2011'''

"Reitoria da Universidade Nova" in the room "Sala do Senado". http://www.unl.pt/onde-estamos/mapa/reitoria

'''Program'''

10:00 am - Welcome and Workshop Introduction

Session 1: Language-based Safety and Security for the Web

10:15 am - João Seco, Data Security with Refinement Types

10:45 am - Luís Caires, Interface Certification for Software Services

11:15 am - Antonio Melo (OutSystems), Validation Issues in web applications.

11:45 am - Discussion

12:00 am - Lunch

Session 2: Enabling Parallelism for the Masses

1:30 pm - Sven Stork, Aeminium language

2:00 pm - Alcides Fonseca, AEminiumGPU: A CPU-GPU Hybrid Runtime for the Æminium Language

2:30 pm - Filipe Martins (Novabase) - TBD

3:00 pm - Discussion

3:15 pm - Break

Session 3: Type-based Static Analysis

3:45 pm - Ijaz Ahmed (UMA) - Automated Verification of Specifications with

Typestates and Access Permissions

4:15 pm - Vasco Vasconcelos, Checking Dynamic Roles in Multiparty Communication

4:45 pm - Discussion and Wrapup

5:15 pm - Informal follow-up

'''Workshop on Facilitating Adoption of Parallel Computing'''

'''Date''': Wednesday, '''May 5, 2010'''

'''Location''': GHC 7501 at CMU

'''Sponsor''': CMU|Portugal Program

With the rise of multicore processors and the increasing richness of application functionality, leveraging parallel computation is increasingly necessary to achieve good performance. However, parallel computing is also difficult for programmers, due to the need to decompose the problem into sub-parts which can be solved in parallel, and due to the challenges of managing potential interference between concurrent tasks.

This workshop focuses on research approaches intended to facilitate the practical adoption of parallel computing. These may include engineering approaches, new models of parallel computing, approaches for verification and reasoning in the presence of concurrency, and approaches for teaching parallel computing.

'''Schedule'''

9:00 Welcome and Workshop Introduction

9:15 Engineering Parallelism: What Works in Practice

10:15 Break

10:30 New Programming Models Facilitating Adoption of Parallelism

12:00 Lunch (provided for workshop participants)

1:00 Verification: Helping Developers Reason about Concurrency

2:00 Hardware Factors in Parallel Computing

2:45 Break

3:00 Teaching Parallel Computing

3:30 Wrapup

4:00 Informal Follow-up

Events

2013-04-19T21:50:03Z

Aeminium: /* 2012 International Workshop on Languages for the Multi-core Era */

== <big>'''2013 International Workshop on Languages for the Multi-core Era'''</big> ==
July 2013, at ECOOP 2013, Montpellier, France
http://www.lirmm.fr/ec-montpellier-2013/
(also colocated with ECMFA and ECSA, and other events)

LaME provides a venue for exploring how languages and related artifacts (e.g., abstractions implemented as libraries, compilers, analysis tools, and parallel runtimes) can make parallel programming safer and more productive, without sacrificing performance. The workshop allows researchers to present new ideas, research directions, and preliminary results in an informal atmosphere that fosters discussion and feedback.

'''MORE INFORMATION AVAILABLE AT http://http://lame2013.dei.uc.pt'''

== <big>'''2012 International Workshop on Languages for the Multi-core Era'''</big> ==
June 13 2012, at ECOOP 2012, Beijing China
http://ecoop12.cs.purdue.edu/
(also colocated with PLDI, ISMM, LCTES, the X10 workshop, and other events)

LaME is an interactive venue for exposing, evaluating, and developing programming language support for concurrency. This workshop provides a forum for the proposal and discussion of creative ideas that spur the development of innovative or improved concurrency models, languages, run-time systems, libraries and tools for multicore programming.

'''MORE INFORMATION AVAILABLE AT http://http://lame.dei.uc.pt'''

==Past Events==

'''Aeminium-Interfaces Joint Workshop, November 9th 2011'''

"Reitoria da Universidade Nova" in the room "Sala do Senado". http://www.unl.pt/onde-estamos/mapa/reitoria

'''Program'''

10:00 am - Welcome and Workshop Introduction

Session 1: Language-based Safety and Security for the Web

10:15 am - João Seco, Data Security with Refinement Types

10:45 am - Luís Caires, Interface Certification for Software Services

11:15 am - Antonio Melo (OutSystems), Validation Issues in web applications.

11:45 am - Discussion

12:00 am - Lunch

Session 2: Enabling Parallelism for the Masses

1:30 pm - Sven Stork, Aeminium language

2:00 pm - Alcides Fonseca, AEminiumGPU: A CPU-GPU Hybrid Runtime for the Æminium Language

2:30 pm - Filipe Martins (Novabase) - TBD

3:00 pm - Discussion

3:15 pm - Break

Session 3: Type-based Static Analysis

3:45 pm - Ijaz Ahmed (UMA) - Automated Verification of Specifications with

Typestates and Access Permissions

4:15 pm - Vasco Vasconcelos, Checking Dynamic Roles in Multiparty Communication

4:45 pm - Discussion and Wrapup

5:15 pm - Informal follow-up

'''Workshop on Facilitating Adoption of Parallel Computing'''

'''Date''': Wednesday, '''May 5, 2010'''

'''Location''': GHC 7501 at CMU

'''Sponsor''': CMU|Portugal Program

With the rise of multicore processors and the increasing richness of application functionality, leveraging parallel computation is increasingly necessary to achieve good performance. However, parallel computing is also difficult for programmers, due to the need to decompose the problem into sub-parts which can be solved in parallel, and due to the challenges of managing potential interference between concurrent tasks.

This workshop focuses on research approaches intended to facilitate the practical adoption of parallel computing. These may include engineering approaches, new models of parallel computing, approaches for verification and reasoning in the presence of concurrency, and approaches for teaching parallel computing.

'''Schedule'''

9:00 Welcome and Workshop Introduction

9:15 Engineering Parallelism: What Works in Practice

10:15 Break

10:30 New Programming Models Facilitating Adoption of Parallelism

12:00 Lunch (provided for workshop participants)

1:00 Verification: Helping Developers Reason about Concurrency

2:00 Hardware Factors in Parallel Computing

2:45 Break

3:00 Teaching Parallel Computing

3:30 Wrapup

4:00 Informal Follow-up

Dissemination

2013-04-19T21:43:49Z

Aeminium: /* Thesis */

== Publications ==

Néstor Cataño and Ijaz Ahmed and Jonathan Aldrich and Radu Siminiceanu, Lightweight Verification of a Multi-Task Threaded Server, in Science of Computer Programming, 2013.

Alcides Fonseca and Cabral, B. ,AeminiumGPU: An Intelligent Framework for GPU Programming, in Facing the Multicore-Challenge III, 2012

Radu I. Siminiceanu Ijaz Ahmed and Néstor Catanõ, Automated Verification of Specifications with Typestates and Access Permissions, in Proceedings of the 12th International Workshop on Automated Verification of Critical Systems (AVoCS 2012), Electronic Communications of the EASST, September 2012.

C. Olarte and E. Pimentel and N. Cataño and C. Rueda, A Linear Concurrent Constraint approach for the automatic verification of access permissions, in Proceedings of the 14th symposium on Principles and practice of declarative programming (PPDP), ACM Press, September 2012.

Alcides Fonseca, Bruno Cabral, Handling Exceptions in Programs with Hidden Concurrency: New Challenges for "Old" Solutions, in ICSE'12 Workshop Proceedings, 5th International Workshop on Exception Handling (WEH.12), Zurich, Switzerland, June, 2012.

Néstor Cataño and Ijaz Ahmed, Lightweight Veriﬁcation of a Multi-Task Threaded Server: A Case Study With The Plural Tool, in Proceedings of 16th International Workshop on Formal Methods for Industrial Critical Systems (FMICS'11), Trento, Italy, August 29-30, 2011 [http://aeminium.dei.uc.pt/images/6/67/Mtts.pdf]

Nels E. Beckman, Duri Kim, and Jonathan Aldrich, An Empirical Study of Object Protocols in the Wild, in Proceedings of the European Conference on Object-Oriented Programming (ECOOP '11), 2011. [http://www.cs.cmu.edu/~aldrich/papers/aldrich-empirical-ecoop11.pdf]

Roger Wolff, Ronald Garcia, Éric Tanter, and Jonathan Aldrich, Gradual Typestate, in Proceedings of the European Conference on Object-Oriented Programming (ECOOP '11), 2011. [http://www.cs.cmu.edu/~aldrich/papers/aldrich-gradual-ecoop11.pdf]

Ligia Nistor and Jonathan Aldrich, Verifying Object-Oriented Code Using Object Propositions, in International Workshop on Aliasing, Confinement and Ownership in object-oriented programming (IWACO), 2011. [http://www.cs.cmu.edu/~aldrich/papers/nistor-iwaco11.pdf]

Joshua Sunshine, Karl Naden, Sven Stork, Jonathan Aldrich, and Éric Tanter, First-Class State Change in Plaid, To appear in Proceedings of Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA '11), 2011, [http://www.cs.cmu.edu/~aldrich/papers/plaid-oopsla11.pdf]

David Alves, Pedro Bizarro and Paulo Marques, Deadline Queries: Leveraging the Cloud to Produce On-Time Results, in Proceedings of the Fourth IEEE International Conference on Cloud Computing (CLOUD 2011), July 4-9, 2011, Washington Marriott, Washington DC, USA, [http://aeminium.dei.uc.pt/images/5/5a/Paper_cloud_2011_cr_final_v2.pdf]

Jonathan Aldrich, Ronald Garcia, Mark Hahnenberg, Manuel Mohr, Karl Naden, Darpan Saini, Sven Stork, Joshua Sunshine, Éric Tanter, and Roger Wolff,
Permission-Based Programming Languages (NIER Track), in Proceedings of the International Conference on Software Engineering (ICSE '11), New Ideas and Emerging Results Track, 2011, [http://www.cs.cmu.edu/~aldrich/papers/plaid-NIER2010.pdf]

Filipe Militão, Jonathan Aldrich, and Luís Caires, Aliasing Control with View-Based Typestate, in Proceedings of Formal Techniques for Java Like Programs (FTfJP), 2010. [http://www.cs.cmu.edu/~aldrich/papers/ftfjp2010-view.pdf]

Sven Stork, Paulo Marques, Jonathan Aldrich. Concurrency by Default: Using Permissions to Express Dataflow in Stateful Programs. Onward! Conference, Orlando, Florida, USA, October, 2009, [http://www.cs.cmu.edu/~svens/papers/onward-2009.pdf].

== Thesis ==

Sven Stork, ÆMINIUM - Freeing Programmers from the Shackles of Sequentiality, thesis submitted to the University of Coimbra and Carnegie Mellon University in fulfilment of the requirement for the degree of Doctor of Philosophy, March 2013.

Ijaz Ahmed, On the Formal Verification of Specifications based on Typestates with Access Permissions, thesis submitted to the University of Madeira in fulfilment of the requirement for the degree of Doctor of Philosophy, December 2012.

Alcides Fonseca, Strategies for Optimization of Parallel Programs, PhD Thesis Proposal, Coimbra, Portugal, September 2012.

Alcides Fonseca, ÆminiumGPU: A CPU-GPU Hybrid Runtime for the Æminium Language, thesis submitted to the University of Coimbra for obtaining the Masters’ Degree in Informatics Engineering, September 2011 [http://aeminium.dei.uc.pt/images/7/73/Alcides_fonseca_msc_thesis.pdf]

Manuel Mohr, AEminium Compilation Theory in the Context of the Plaid Language, Diploma thesis submitted to the Karlsruhe Institute of
Technology, February 2011 [http://pp.info.uni-karlsruhe.de/~mohr/DiplomaThesisMohr.pdf]

Sven Stork, Concurrent Programming via Access Permissions, PhD Thesis Proposal, Coimbra, Portugal, September 2009, [http://www.cs.cmu.edu/~svens/papers/proposal-2009.pdf].

== Internal Presentations ==

July 2011: [http://aeminium.dei.uc.pt/images/6/6a/Presentation.pdf Pulse: Plural To EVMDD-SMC - The Compiler and Model Generator]

March 2011 at Novabase: [http://aeminium.dei.uc.pt/images/0/05/Novabase.pdf Lightweight Verification of a Multi-Task Threaded Server: A Case Study With The Plural Tool]

== Public Presentations ==

Jonathan Aldrich, Ronald Garcia, Mark Hahnenberg, Manuel Mohr, Karl Naden, Darpan Saini, Sven Stork, Joshua Sunshine, Éric Tanter, and Roger Wolff. Permission-Based Programming Languages (NIER Track). At the International Conference on Software Engineering (ICSE '11), New Ideas and Emerging Results Track, 2011 [http://aeminium.dei.uc.pt/images/9/91/Plaidpermissions-icsenier-may11.pdf Plaidpermissions-icsenier-may11.pdf]

Concurrency-Workshop 2010: [http://aeminium.dei.uc.pt/images/a/ae/AEminium-in-a-Nutshell.pdf AEminium-in-a-Nutshell.pdf]

UC/Seminar presentation January 2009: [http://aeminium.dei.uc.pt/images/1/1e/Designing-a-Concurrent-Programming-Language.pdf Designing-a-Concurrent-Programming-Language.pdf]

SSSG talk 2009: [http://aeminium.dei.uc.pt/images/a/a6/SSSG-Conurrency-by-Default.pdf SSSG-Concurrency-by-Default.pdf]

PhD-Proposal short presentation: [http://aeminium.dei.uc.pt/images/6/6c/Concurrent-Programming-via-Access-Permissions.pdf Concurrent-Programming-via-Access-Permissions.pdf]

Phd-Proposal UC: [http://aeminium.dei.uc.pt/images/f/f6/PhD-Proposal-Defense-UC.pdf PhD-Proposal-Defense-UC.pdf]

Onward 2009: [http://aeminium.dei.uc.pt/images/f/ff/Concurrency-By-Default.pdf Concurreny-By-Default.pdf]

SSSG 2008: [http://aeminium.dei.uc.pt/images/e/e2/ParallelProgrammingModels.pdf Parallel-Programming-Models.pdf]

SSSG 2008: [http://aeminium.dei.uc.pt/images/d/d5/SSSG-CurrentResearch.pdf SSSG-CurrentResearch.pdf]

Dissemination

2013-04-19T21:34:43Z

Aeminium: /* Publications */

== Publications ==

Néstor Cataño and Ijaz Ahmed and Jonathan Aldrich and Radu Siminiceanu, Lightweight Verification of a Multi-Task Threaded Server, in Science of Computer Programming, 2013.

Alcides Fonseca and Cabral, B. ,AeminiumGPU: An Intelligent Framework for GPU Programming, in Facing the Multicore-Challenge III, 2012

Radu I. Siminiceanu Ijaz Ahmed and Néstor Catanõ, Automated Verification of Specifications with Typestates and Access Permissions, in Proceedings of the 12th International Workshop on Automated Verification of Critical Systems (AVoCS 2012), Electronic Communications of the EASST, September 2012.

C. Olarte and E. Pimentel and N. Cataño and C. Rueda, A Linear Concurrent Constraint approach for the automatic verification of access permissions, in Proceedings of the 14th symposium on Principles and practice of declarative programming (PPDP), ACM Press, September 2012.

Alcides Fonseca, Bruno Cabral, Handling Exceptions in Programs with Hidden Concurrency: New Challenges for "Old" Solutions, in ICSE'12 Workshop Proceedings, 5th International Workshop on Exception Handling (WEH.12), Zurich, Switzerland, June, 2012.

Néstor Cataño and Ijaz Ahmed, Lightweight Veriﬁcation of a Multi-Task Threaded Server: A Case Study With The Plural Tool, in Proceedings of 16th International Workshop on Formal Methods for Industrial Critical Systems (FMICS'11), Trento, Italy, August 29-30, 2011 [http://aeminium.dei.uc.pt/images/6/67/Mtts.pdf]

Nels E. Beckman, Duri Kim, and Jonathan Aldrich, An Empirical Study of Object Protocols in the Wild, in Proceedings of the European Conference on Object-Oriented Programming (ECOOP '11), 2011. [http://www.cs.cmu.edu/~aldrich/papers/aldrich-empirical-ecoop11.pdf]

Roger Wolff, Ronald Garcia, Éric Tanter, and Jonathan Aldrich, Gradual Typestate, in Proceedings of the European Conference on Object-Oriented Programming (ECOOP '11), 2011. [http://www.cs.cmu.edu/~aldrich/papers/aldrich-gradual-ecoop11.pdf]

Ligia Nistor and Jonathan Aldrich, Verifying Object-Oriented Code Using Object Propositions, in International Workshop on Aliasing, Confinement and Ownership in object-oriented programming (IWACO), 2011. [http://www.cs.cmu.edu/~aldrich/papers/nistor-iwaco11.pdf]

Joshua Sunshine, Karl Naden, Sven Stork, Jonathan Aldrich, and Éric Tanter, First-Class State Change in Plaid, To appear in Proceedings of Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA '11), 2011, [http://www.cs.cmu.edu/~aldrich/papers/plaid-oopsla11.pdf]

David Alves, Pedro Bizarro and Paulo Marques, Deadline Queries: Leveraging the Cloud to Produce On-Time Results, in Proceedings of the Fourth IEEE International Conference on Cloud Computing (CLOUD 2011), July 4-9, 2011, Washington Marriott, Washington DC, USA, [http://aeminium.dei.uc.pt/images/5/5a/Paper_cloud_2011_cr_final_v2.pdf]

Jonathan Aldrich, Ronald Garcia, Mark Hahnenberg, Manuel Mohr, Karl Naden, Darpan Saini, Sven Stork, Joshua Sunshine, Éric Tanter, and Roger Wolff,
Permission-Based Programming Languages (NIER Track), in Proceedings of the International Conference on Software Engineering (ICSE '11), New Ideas and Emerging Results Track, 2011, [http://www.cs.cmu.edu/~aldrich/papers/plaid-NIER2010.pdf]

Filipe Militão, Jonathan Aldrich, and Luís Caires, Aliasing Control with View-Based Typestate, in Proceedings of Formal Techniques for Java Like Programs (FTfJP), 2010. [http://www.cs.cmu.edu/~aldrich/papers/ftfjp2010-view.pdf]

Sven Stork, Paulo Marques, Jonathan Aldrich. Concurrency by Default: Using Permissions to Express Dataflow in Stateful Programs. Onward! Conference, Orlando, Florida, USA, October, 2009, [http://www.cs.cmu.edu/~svens/papers/onward-2009.pdf].

== Thesis ==

Alcides Fonseca, ÆminiumGPU: A CPU-GPU Hybrid Runtime for the Æminium Language, thesis submitted to the University of Coimbra for obtaining the Masters’ Degree in Informatics Engineering, September 2011 [http://aeminium.dei.uc.pt/images/7/73/Alcides_fonseca_msc_thesis.pdf]

Manuel Mohr, AEminium Compilation Theory in the Context of the Plaid Language, Diploma thesis submitted to the Karlsruhe Institute of
Technology, February 2011 [http://pp.info.uni-karlsruhe.de/~mohr/DiplomaThesisMohr.pdf]

Sven Stork, Concurrent Programming via Access Permissions, PhD Thesis Proposal, Coimbra, Portugal, September 2009, [http://www.cs.cmu.edu/~svens/papers/proposal-2009.pdf].

== Internal Presentations ==

July 2011: [http://aeminium.dei.uc.pt/images/6/6a/Presentation.pdf Pulse: Plural To EVMDD-SMC - The Compiler and Model Generator]

March 2011 at Novabase: [http://aeminium.dei.uc.pt/images/0/05/Novabase.pdf Lightweight Verification of a Multi-Task Threaded Server: A Case Study With The Plural Tool]

== Public Presentations ==

Jonathan Aldrich, Ronald Garcia, Mark Hahnenberg, Manuel Mohr, Karl Naden, Darpan Saini, Sven Stork, Joshua Sunshine, Éric Tanter, and Roger Wolff. Permission-Based Programming Languages (NIER Track). At the International Conference on Software Engineering (ICSE '11), New Ideas and Emerging Results Track, 2011 [http://aeminium.dei.uc.pt/images/9/91/Plaidpermissions-icsenier-may11.pdf Plaidpermissions-icsenier-may11.pdf]

Concurrency-Workshop 2010: [http://aeminium.dei.uc.pt/images/a/ae/AEminium-in-a-Nutshell.pdf AEminium-in-a-Nutshell.pdf]

UC/Seminar presentation January 2009: [http://aeminium.dei.uc.pt/images/1/1e/Designing-a-Concurrent-Programming-Language.pdf Designing-a-Concurrent-Programming-Language.pdf]

SSSG talk 2009: [http://aeminium.dei.uc.pt/images/a/a6/SSSG-Conurrency-by-Default.pdf SSSG-Concurrency-by-Default.pdf]

PhD-Proposal short presentation: [http://aeminium.dei.uc.pt/images/6/6c/Concurrent-Programming-via-Access-Permissions.pdf Concurrent-Programming-via-Access-Permissions.pdf]

Phd-Proposal UC: [http://aeminium.dei.uc.pt/images/f/f6/PhD-Proposal-Defense-UC.pdf PhD-Proposal-Defense-UC.pdf]

Onward 2009: [http://aeminium.dei.uc.pt/images/f/ff/Concurrency-By-Default.pdf Concurreny-By-Default.pdf]

SSSG 2008: [http://aeminium.dei.uc.pt/images/e/e2/ParallelProgrammingModels.pdf Parallel-Programming-Models.pdf]

SSSG 2008: [http://aeminium.dei.uc.pt/images/d/d5/SSSG-CurrentResearch.pdf SSSG-CurrentResearch.pdf]

AEminium

2012-05-21T17:41:34Z

Aeminium:

<big>'''Freeing Programmers from the Shackles of Sequentiality.'''</big>

Current programming systems shackle developers to a sequential coding paradigm.
This paradigm hampers developers from taking advantage of emerging large‐scale multicore hardware. We propose a platform which builds in concurrency by default: instead of sequencing code, programmers express dependency information, which is used by a compile‐time checker to verify correctness conditions, and by the libraries and runtime system to enable concurrent execution. As a result, developers can write parallel code in a natural style and have confidence in its correctness and performance.

Consult the [http://aeminium.dei.uc.pt/images/1/13/Aeminium_ExecutiveSummary.pdf Executive Summary] for information on the project.

<big>'''2012 International Workshop on Languages for the Multi-core Era'''</big>
June 13 2012, at ECOOP 2012, Beijing China
http://ecoop12.cs.purdue.edu/
(also colocated with PLDI, ISMM, LCTES, the X10 workshop, and other events)

LaME is an interactive venue for exposing, evaluating, and developing programming language support for concurrency. This workshop provides a forum for the proposal and discussion of creative ideas that spur the development of innovative or improved concurrency models, languages, run-time systems, libraries and tools for multicore programming.

'''MORE INFORMATION AVAILABLE AT http://http://lame.dei.uc.pt'''

== AEminium at the University of Coimbra ==
AEminiumGPU [http://aeminium.dei.uc.pt/images/7/73/Alcides_fonseca_msc_thesis.pdf] is a sub-project of the AEminium project. It provides an high-level programming framework for developing parallel programs for both CPUs and GPUs. AEminiumGPU drives inspiration from Functional Programming and currently allows developers to implement programs based on the Map-Reduce pattern. In the future, the framework can be extended with other higher-order functions. AEminiumGPU does not force developers to understand the particularities of GPU programming. Programs can be written in pure Java (and soon AEminium) but specific parts of the code are compiled to OpenCL and executed on the GPU.

AEMiniumGPU is a framework composed by a compiler and a runtime. It is available for download the following address: https://github.com/alcides/AeminiumGPUCompiler/

== AEminium at the University of Madeira ==

The organizers of FMICS'11 selected the article "Multi-Task Threaded Server: A Case Study With The Plural Tool" by Néstor Cataño and Ijaz Ahmed for submission to Science of Computer Programming (SCP). FMICS invited 7 papers in total and will select 5 of them for final publication to SCP. This article discusses the business case provided by AEMinium's industrial partner Novabase.

Follow this [http://www3.uma.pt/ncatano/aeminium/Home.html link] for more information on what the University of Madeira is doing on the AEminium project.

== AEminium at the Carnegie Mellon University ==
Contact Jonathan Aldrich at CMU for more information. http://www.cs.cmu.edu/~aldrich/

== AEminium source code ==
Check out [http://code.google.com/p/aeminium/ Google Code] for code and examples (under development).

AEminium

2012-05-21T17:39:45Z

Aeminium:

<big>'''Freeing Programmers from the Shackles of Sequentiality.'''</big>

Current programming systems shackle developers to a sequential coding paradigm.
This paradigm hampers developers from taking advantage of emerging large‐scale multicore hardware. We propose a platform which builds in concurrency by default: instead of sequencing code, programmers express dependency information, which is used by a compile‐time checker to verify correctness conditions, and by the libraries and runtime system to enable concurrent execution. As a result, developers can write parallel code in a natural style and have confidence in its correctness and performance.

Consult the [http://aeminium.dei.uc.pt/images/1/13/Aeminium_ExecutiveSummary.pdf Executive Summary] for information on the project.

<big>'''2012 International Workshop on Languages for the Multi-core Era'''</big>
June 13 2012, at ECOOP 2012, Beijing China
http://ecoop12.cs.purdue.edu/
(also colocated with PLDI, ISMM, LCTES, the X10 workshop, and other events)

LaME is an interactive venue for exposing, evaluating, and developing programming language support for concurrency. This workshop provides a forum for the proposal and discussion of creative ideas that spur the development of innovative or improved concurrency models, languages, run-time systems, libraries and tools for multicore programming.

'''MORE INFORMATION AVAILABLE AT http://http://lame.dei.uc.pt'''

== AEminium at the University of Coimbra ==
AEminiumGPU [http://aeminium.dei.uc.pt/images/7/73/Alcides_fonseca_msc_thesis.pdf] is a sub-project of the AEminium project. It provides an high-level programming framework for developing parallel programs for both CPUs and GPUs. AEminiumGPU drives inspiration from Functional Programming and currently allows developers to implement programs based on the Map-Reduce pattern. In the future, the framework can be extended with other higher-order functions. AEminiumGPU does not force developers to understand the particularities of GPU programming. Programs can be written in pure Java (and soon AEminium) but specific parts of the code are compiled to OpenCL and executed on the GPU.

AEMiniumGPU is a framework composed by a compiler and a runtime. It is available for download the following address: https://github.com/alcides/AeminiumGPUCompiler/

== AEminium at the University of Madeira ==

The organizers of FMICS'11 selected the article "Multi-Task Threaded Server: A Case Study With The Plural Tool" by Néstor Cataño and Ijaz Ahmed for submission to Science of Computer Programming (SCP). FMICS invited 7 papers in total and will select 5 of them for final publication to SCP. This article discusses the business case provided by AEMinium's industrial partner Novabase.

Follow this [http://www3.uma.pt/ncatano/aeminium/Home.html link] for more information on what the University of Madeira is doing on the AEminium project.

== AEminium source code ==
Check out [http://code.google.com/p/aeminium/ Google Code] for code and examples (under development).

AEminium

2012-05-21T17:39:32Z

Aeminium:

<big>'''Freeing Programmers from the Shackles of Sequentiality.'''</big>

Current programming systems shackle developers to a sequential coding paradigm.
This paradigm hampers developers from taking advantage of emerging large‐scale multicore hardware. We propose a platform which builds in concurrency by default: instead of sequencing code, programmers express dependency information, which is used by a compile‐time checker to verify correctness conditions, and by the libraries and runtime system to enable concurrent execution. As a result, developers can write parallel code in a natural style and have confidence in its correctness and performance.

Consult the [http://aeminium.dei.uc.pt/images/1/13/Aeminium_ExecutiveSummary.pdf Executive Summary] for information on the project.

<big>'''2012 International Workshop on Languages for the Multi-core Era'''</big>
June 13 2012, at ECOOP 2012, Beijing China
http://ecoop12.cs.purdue.edu/
(also colocated with PLDI, ISMM, LCTES, the X10 workshop, and other events)

LaME is an interactive venue for exposing, evaluating, and developing programming language support for concurrency. This workshop provides a forum for the proposal and discussion of creative ideas that spur the development of innovative or improved concurrency models, languages, run-time systems, libraries and tools for multicore programming.

'''MORE INFORMATION AVAILABLE AT http://http://lame.dei.uc.pt'''

== AEminium at the University of Coimbra ==
AEminiumGPU [http://aeminium.dei.uc.pt/images/7/73/Alcides_fonseca_msc_thesis.pdf] is a sub-project of the AEminium project. It provides an high-level programming framework for developing parallel programs for both CPUs and GPUs. AEminiumGPU drives inspiration from Functional Programming and currently allows developers to implement programs based on the Map-Reduce pattern. In the future, the framework can be extended with other higher-order functions. AEminiumGPU does not force developers to understand the particularities of GPU programming. Programs can be written in pure Java (and soon AEminium) but specific parts of the code are compiled to OpenCL and executed on the GPU.

AEMiniumGPU is a framework composed by a compiler and a runtime. It is available for download the following address: https://github.com/alcides/AeminiumGPUCompiler/

== AEminium at the University of Madeira ==

The organizers of FMICS'11 selected the article "Multi-Task Threaded Server: A Case Study With The Plural Tool" by Néstor Cataño and Ijaz Ahmed for submission to Science of Computer Programming (SCP). FMICS invited 7 papers in total and will select 5 of them for final publication to SCP. This article discusses the business case provided by AEMinium's industrial partner Novabase.

Follow this [http://www3.uma.pt/ncatano/aeminium/Home.html link] for more information on what the University of Madeira is doing on the AEminium project.

== AEminium source code ==
Check out [http://code.google.com/p/aeminium/ Google Code] for code and examples (under development).

AEminium

2012-05-21T17:39:20Z

Aeminium:

<big>'''Freeing Programmers from the Shackles of Sequentiality.'''</big>

Current programming systems shackle developers to a sequential coding paradigm.
This paradigm hampers developers from taking advantage of emerging large‐scale multicore hardware. We propose a platform which builds in concurrency by default: instead of sequencing code, programmers express dependency information, which is used by a compile‐time checker to verify correctness conditions, and by the libraries and runtime system to enable concurrent execution. As a result, developers can write parallel code in a natural style and have confidence in its correctness and performance.

Consult the [http://aeminium.dei.uc.pt/images/1/13/Aeminium_ExecutiveSummary.pdf Executive Summary] for information on the project.

<big>'''2012 International Workshop on Languages for the Multi-core Era'''</big>
June 13 2012, at ECOOP 2012, Beijing China
http://ecoop12.cs.purdue.edu/
(also colocated with PLDI, ISMM, LCTES, the X10 workshop, and other events)

LaME is an interactive venue for exposing, evaluating, and developing programming language support for concurrency. This workshop provides a forum for the proposal and discussion of creative ideas that spur the development of innovative or improved concurrency models, languages, run-time systems, libraries and tools for multicore programming.

'''MORE INFORMATION AVAILABLE AT http://http://lame.dei.uc.pt'''

== AEminium at the University of Coimbra ==
AEminiumGPU [http://aeminium.dei.uc.pt/images/7/73/Alcides_fonseca_msc_thesis.pdf] is a sub-project of the AEminium project. It provides an high-level programming framework for developing parallel programs for both CPUs and GPUs. AEminiumGPU drives inspiration from Functional Programming and currently allows developers to implement programs based on the Map-Reduce pattern. In the future, the framework can be extended with other higher-order functions. AEminiumGPU does not force developers to understand the particularities of GPU programming. Programs can be written in pure Java (and soon AEminium) but specific parts of the code are compiled to OpenCL and executed on the GPU.

AEMiniumGPU is a framework composed by a compiler and a runtime. It is available for download the following address: https://github.com/alcides/AeminiumGPUCompiler/

== AEminium at the University of Madeira ==

The organizers of FMICS'11 selected the article "Multi-Task Threaded Server: A Case Study With The Plural Tool" by Néstor Cataño and Ijaz Ahmed for submission to Science of Computer Programming (SCP). FMICS invited 7 papers in total and will select 5 of them for final publication to SCP. This article discusses the business case provided by AEMinium's industrial partner Novabase.

Follow this [http://www3.uma.pt/ncatano/aeminium/Home.html link] for more information on what the University of Madeira is doing on the AEminium project.

== AEminium source code ==
Check out [http://code.google.com/p/aeminium/ Google Code] for code and examples (under development).

AEminium

2012-05-21T17:38:59Z

Aeminium:

<big>'''Freeing Programmers from the Shackles of Sequentiality.'''</big>

Current programming systems shackle developers to a sequential coding paradigm.
This paradigm hampers developers from taking advantage of emerging large‐scale multicore hardware. We propose a platform which builds in concurrency by default: instead of sequencing code, programmers express dependency information, which is used by a compile‐time checker to verify correctness conditions, and by the libraries and runtime system to enable concurrent execution. As a result, developers can write parallel code in a natural style and have confidence in its correctness and performance.

Consult the [http://aeminium.dei.uc.pt/images/1/13/Aeminium_ExecutiveSummary.pdf Executive Summary] for information on the project.

== <big>'''2012 International Workshop on Languages for the Multi-core Era'''</big> ==
June 13 2012, at ECOOP 2012, Beijing China
http://ecoop12.cs.purdue.edu/
(also colocated with PLDI, ISMM, LCTES, the X10 workshop, and other events)

LaME is an interactive venue for exposing, evaluating, and developing programming language support for concurrency. This workshop provides a forum for the proposal and discussion of creative ideas that spur the development of innovative or improved concurrency models, languages, run-time systems, libraries and tools for multicore programming.

'''MORE INFORMATION AVAILABLE AT http://http://lame.dei.uc.pt'''

== AEminium at the University of Coimbra ==
AEminiumGPU [http://aeminium.dei.uc.pt/images/7/73/Alcides_fonseca_msc_thesis.pdf] is a sub-project of the AEminium project. It provides an high-level programming framework for developing parallel programs for both CPUs and GPUs. AEminiumGPU drives inspiration from Functional Programming and currently allows developers to implement programs based on the Map-Reduce pattern. In the future, the framework can be extended with other higher-order functions. AEminiumGPU does not force developers to understand the particularities of GPU programming. Programs can be written in pure Java (and soon AEminium) but specific parts of the code are compiled to OpenCL and executed on the GPU.

AEMiniumGPU is a framework composed by a compiler and a runtime. It is available for download the following address: https://github.com/alcides/AeminiumGPUCompiler/

== AEminium at the University of Madeira ==

The organizers of FMICS'11 selected the article "Multi-Task Threaded Server: A Case Study With The Plural Tool" by Néstor Cataño and Ijaz Ahmed for submission to Science of Computer Programming (SCP). FMICS invited 7 papers in total and will select 5 of them for final publication to SCP. This article discusses the business case provided by AEMinium's industrial partner Novabase.

Follow this [http://www3.uma.pt/ncatano/aeminium/Home.html link] for more information on what the University of Madeira is doing on the AEminium project.

== AEminium source code ==
Check out [http://code.google.com/p/aeminium/ Google Code] for code and examples (under development).

Events

2012-05-21T17:38:00Z

Aeminium:

== <big>'''2012 International Workshop on Languages for the Multi-core Era'''</big> ==
June 13 2012, at ECOOP 2012, Beijing China
http://ecoop12.cs.purdue.edu/
(also colocated with PLDI, ISMM, LCTES, the X10 workshop, and other events)

LaME is an interactive venue for exposing, evaluating, and developing programming language support for concurrency. This workshop provides a forum for the proposal and discussion of creative ideas that spur the development of innovative or improved concurrency models, languages, run-time systems, libraries and tools for multicore programming.

'''MORE INFORMATION AVAILABLE AT http://http://lame.dei.uc.pt'''

==Past Events==

'''Aeminium-Interfaces Joint Workshop, November 9th 2011'''

"Reitoria da Universidade Nova" in the room "Sala do Senado". http://www.unl.pt/onde-estamos/mapa/reitoria

'''Program'''

10:00 am - Welcome and Workshop Introduction

Session 1: Language-based Safety and Security for the Web

10:15 am - João Seco, Data Security with Refinement Types

10:45 am - Luís Caires, Interface Certification for Software Services

11:15 am - Antonio Melo (OutSystems), Validation Issues in web applications.

11:45 am - Discussion

12:00 am - Lunch

Session 2: Enabling Parallelism for the Masses

1:30 pm - Sven Stork, Aeminium language

2:00 pm - Alcides Fonseca, AEminiumGPU: A CPU-GPU Hybrid Runtime for the Æminium Language

2:30 pm - Filipe Martins (Novabase) - TBD

3:00 pm - Discussion

3:15 pm - Break

Session 3: Type-based Static Analysis

3:45 pm - Ijaz Ahmed (UMA) - Automated Verification of Specifications with

Typestates and Access Permissions

4:15 pm - Vasco Vasconcelos, Checking Dynamic Roles in Multiparty Communication

4:45 pm - Discussion and Wrapup

5:15 pm - Informal follow-up

'''Workshop on Facilitating Adoption of Parallel Computing'''

'''Date''': Wednesday, '''May 5, 2010'''

'''Location''': GHC 7501 at CMU

'''Sponsor''': CMU|Portugal Program

With the rise of multicore processors and the increasing richness of application functionality, leveraging parallel computation is increasingly necessary to achieve good performance. However, parallel computing is also difficult for programmers, due to the need to decompose the problem into sub-parts which can be solved in parallel, and due to the challenges of managing potential interference between concurrent tasks.

This workshop focuses on research approaches intended to facilitate the practical adoption of parallel computing. These may include engineering approaches, new models of parallel computing, approaches for verification and reasoning in the presence of concurrency, and approaches for teaching parallel computing.

'''Schedule'''

9:00 Welcome and Workshop Introduction

9:15 Engineering Parallelism: What Works in Practice

10:15 Break

10:30 New Programming Models Facilitating Adoption of Parallelism

12:00 Lunch (provided for workshop participants)

1:00 Verification: Helping Developers Reason about Concurrency

2:00 Hardware Factors in Parallel Computing

2:45 Break

3:00 Teaching Parallel Computing

3:30 Wrapup

4:00 Informal Follow-up

Events

2012-05-21T17:36:28Z

Aeminium:

'''Aeminium-Interfaces Joint Workshop, November 9th 2011'''

"Reitoria da Universidade Nova" in the room "Sala do Senado". http://www.unl.pt/onde-estamos/mapa/reitoria

'''Program'''

10:00 am - Welcome and Workshop Introduction

Session 1: Language-based Safety and Security for the Web

10:15 am - João Seco, Data Security with Refinement Types

10:45 am - Luís Caires, Interface Certification for Software Services

11:15 am - Antonio Melo (OutSystems), Validation Issues in web applications.

11:45 am - Discussion

12:00 am - Lunch

Session 2: Enabling Parallelism for the Masses

1:30 pm - Sven Stork, Aeminium language

2:00 pm - Alcides Fonseca, AEminiumGPU: A CPU-GPU Hybrid Runtime for the Æminium Language

2:30 pm - Filipe Martins (Novabase) - TBD

3:00 pm - Discussion

3:15 pm - Break

Session 3: Type-based Static Analysis

3:45 pm - Ijaz Ahmed (UMA) - Automated Verification of Specifications with

Typestates and Access Permissions

4:15 pm - Vasco Vasconcelos, Checking Dynamic Roles in Multiparty Communication

4:45 pm - Discussion and Wrapup

5:15 pm - Informal follow-up

==Past Events==
'''Workshop on Facilitating Adoption of Parallel Computing'''

'''Date''': Wednesday, '''May 5, 2010'''

'''Location''': GHC 7501 at CMU

'''Sponsor''': CMU|Portugal Program

With the rise of multicore processors and the increasing richness of application functionality, leveraging parallel computation is increasingly necessary to achieve good performance. However, parallel computing is also difficult for programmers, due to the need to decompose the problem into sub-parts which can be solved in parallel, and due to the challenges of managing potential interference between concurrent tasks.

This workshop focuses on research approaches intended to facilitate the practical adoption of parallel computing. These may include engineering approaches, new models of parallel computing, approaches for verification and reasoning in the presence of concurrency, and approaches for teaching parallel computing.

'''Schedule'''

9:00 Welcome and Workshop Introduction

9:15 Engineering Parallelism: What Works in Practice

10:15 Break

10:30 New Programming Models Facilitating Adoption of Parallelism

12:00 Lunch (provided for workshop participants)

1:00 Verification: Helping Developers Reason about Concurrency

2:00 Hardware Factors in Parallel Computing

2:45 Break

3:00 Teaching Parallel Computing

3:30 Wrapup

4:00 Informal Follow-up

Events

2012-05-21T17:36:08Z

Aeminium:

'''Aeminium-Interfaces Joint Workshop, November 9th 2011'''

"Reitoria da Universidade Nova" in the room "Sala do Senado". http://www.unl.pt/onde-estamos/mapa/reitoria

Program

10:00 am - Welcome and Workshop Introduction

Session 1: Language-based Safety and Security for the Web

10:15 am - João Seco, Data Security with Refinement Types

10:45 am - Luís Caires, Interface Certification for Software Services

11:15 am - Antonio Melo (OutSystems), Validation Issues in web applications.

11:45 am - Discussion

12:00 am - Lunch

Session 2: Enabling Parallelism for the Masses

1:30 pm - Sven Stork, Aeminium language

2:00 pm - Alcides Fonseca, AEminiumGPU: A CPU-GPU Hybrid Runtime for the Æminium Language

2:30 pm - Filipe Martins (Novabase) - TBD

3:00 pm - Discussion

3:15 pm - Break

Session 3: Type-based Static Analysis

3:45 pm - Ijaz Ahmed (UMA) - Automated Verification of Specifications with

Typestates and Access Permissions

4:15 pm - Vasco Vasconcelos, Checking Dynamic Roles in Multiparty Communication

4:45 pm - Discussion and Wrapup

5:15 pm - Informal follow-up

==Past Events==
'''Workshop on Facilitating Adoption of Parallel Computing'''

'''Date''': Wednesday, '''May 5, 2010'''

'''Location''': GHC 7501 at CMU

'''Sponsor''': CMU|Portugal Program

With the rise of multicore processors and the increasing richness of application functionality, leveraging parallel computation is increasingly necessary to achieve good performance. However, parallel computing is also difficult for programmers, due to the need to decompose the problem into sub-parts which can be solved in parallel, and due to the challenges of managing potential interference between concurrent tasks.

This workshop focuses on research approaches intended to facilitate the practical adoption of parallel computing. These may include engineering approaches, new models of parallel computing, approaches for verification and reasoning in the presence of concurrency, and approaches for teaching parallel computing.

'''Schedule'''

9:00 Welcome and Workshop Introduction

9:15 Engineering Parallelism: What Works in Practice

10:15 Break

10:30 New Programming Models Facilitating Adoption of Parallelism

12:00 Lunch (provided for workshop participants)

1:00 Verification: Helping Developers Reason about Concurrency

2:00 Hardware Factors in Parallel Computing

2:45 Break

3:00 Teaching Parallel Computing

3:30 Wrapup

4:00 Informal Follow-up

Events

2012-05-21T17:35:51Z

Aeminium:

'''Aeminium-Interfaces Joint Workshop, November 9th 2011'''

"Reitoria da Universidade Nova" in the room "Sala do Senado". http://www.unl.pt/onde-estamos/mapa/reitoria

Program

10:00 am - Welcome and Workshop Introduction

Session 1: Language-based Safety and Security for the Web

10:15 am - João Seco, Data Security with Refinement Types

10:45 am - Luís Caires, Interface Certification for Software Services

11:15 am - Antonio Melo (OutSystems), Validation Issues in web applications.

11:45 am - Discussion

12:00 am - Lunch

Session 2: Enabling Parallelism for the Masses

1:30 pm - Sven Stork, Aeminium language

2:00 pm - Alcides Fonseca, AEminiumGPU: A CPU-GPU Hybrid Runtime for the

Æminium Language

2:30 pm - Filipe Martins (Novabase) - TBD

3:00 pm - Discussion

3:15 pm - Break

Session 3: Type-based Static Analysis

3:45 pm - Ijaz Ahmed (UMA) - Automated Verification of Specifications with

Typestates and Access Permissions

4:15 pm - Vasco Vasconcelos, Checking Dynamic Roles in Multiparty Communication

4:45 pm - Discussion and Wrapup

5:15 pm - Informal follow-up

==Past Events==
'''Workshop on Facilitating Adoption of Parallel Computing'''

'''Date''': Wednesday, '''May 5, 2010'''

'''Location''': GHC 7501 at CMU

'''Sponsor''': CMU|Portugal Program

With the rise of multicore processors and the increasing richness of application functionality, leveraging parallel computation is increasingly necessary to achieve good performance. However, parallel computing is also difficult for programmers, due to the need to decompose the problem into sub-parts which can be solved in parallel, and due to the challenges of managing potential interference between concurrent tasks.

This workshop focuses on research approaches intended to facilitate the practical adoption of parallel computing. These may include engineering approaches, new models of parallel computing, approaches for verification and reasoning in the presence of concurrency, and approaches for teaching parallel computing.

'''Schedule'''

9:00 Welcome and Workshop Introduction

9:15 Engineering Parallelism: What Works in Practice

10:15 Break

10:30 New Programming Models Facilitating Adoption of Parallelism

12:00 Lunch (provided for workshop participants)

1:00 Verification: Helping Developers Reason about Concurrency

2:00 Hardware Factors in Parallel Computing

2:45 Break

3:00 Teaching Parallel Computing

3:30 Wrapup

4:00 Informal Follow-up

Events

2012-05-21T17:35:27Z

Aeminium:

'''Aeminium-Interfaces Joint Workshop, November 9th 2011'''
"Reitoria da Universidade Nova" in the room "Sala do Senado". http://www.unl.pt/onde-estamos/mapa/reitoria

Program
10:00 am - Welcome and Workshop Introduction
Session 1: Language-based Safety and Security for the Web
10:15 am - João Seco, Data Security with Refinement Types
10:45 am - Luís Caires, Interface Certification for Software Services
11:15 am - Antonio Melo (OutSystems), Validation Issues in web applications.
11:45 am - Discussion
12:00 am - Lunch
Session 2: Enabling Parallelism for the Masses
1:30 pm - Sven Stork, Aeminium language
2:00 pm - Alcides Fonseca, AEminiumGPU: A CPU-GPU Hybrid Runtime for the
Æminium Language
2:30 pm - Filipe Martins (Novabase) - TBD
3:00 pm - Discussion
3:15 pm - Break
Session 3: Type-based Static Analysis
3:45 pm - Ijaz Ahmed (UMA) - Automated Verification of Specifications with
Typestates and Access Permissions
4:15 pm - Vasco Vasconcelos, Checking Dynamic Roles in Multiparty Communication
4:45 pm - Discussion and Wrapup
5:15 pm - Informal follow-up

==Past Events==
'''Workshop on Facilitating Adoption of Parallel Computing'''

'''Date''': Wednesday, '''May 5, 2010'''

'''Location''': GHC 7501 at CMU

'''Sponsor''': CMU|Portugal Program

With the rise of multicore processors and the increasing richness of application functionality, leveraging parallel computation is increasingly necessary to achieve good performance. However, parallel computing is also difficult for programmers, due to the need to decompose the problem into sub-parts which can be solved in parallel, and due to the challenges of managing potential interference between concurrent tasks.

This workshop focuses on research approaches intended to facilitate the practical adoption of parallel computing. These may include engineering approaches, new models of parallel computing, approaches for verification and reasoning in the presence of concurrency, and approaches for teaching parallel computing.

'''Schedule'''

9:00 Welcome and Workshop Introduction

9:15 Engineering Parallelism: What Works in Practice

10:15 Break

10:30 New Programming Models Facilitating Adoption of Parallelism

12:00 Lunch (provided for workshop participants)

1:00 Verification: Helping Developers Reason about Concurrency

2:00 Hardware Factors in Parallel Computing

2:45 Break

3:00 Teaching Parallel Computing

3:30 Wrapup

4:00 Informal Follow-up

AEminium

2012-05-21T17:31:47Z

Aeminium:

<big>'''Freeing Programmers from the Shackles of Sequentiality.'''</big>

Current programming systems shackle developers to a sequential coding paradigm.
This paradigm hampers developers from taking advantage of emerging large‐scale multicore hardware. We propose a platform which builds in concurrency by default: instead of sequencing code, programmers express dependency information, which is used by a compile‐time checker to verify correctness conditions, and by the libraries and runtime system to enable concurrent execution. As a result, developers can write parallel code in a natural style and have confidence in its correctness and performance.

Consult the [http://aeminium.dei.uc.pt/images/1/13/Aeminium_ExecutiveSummary.pdf Executive Summary] for information on the project.

== AEminium at the University of Coimbra ==
AEminiumGPU [http://aeminium.dei.uc.pt/images/7/73/Alcides_fonseca_msc_thesis.pdf] is a sub-project of the AEminium project. It provides an high-level programming framework for developing parallel programs for both CPUs and GPUs. AEminiumGPU drives inspiration from Functional Programming and currently allows developers to implement programs based on the Map-Reduce pattern. In the future, the framework can be extended with other higher-order functions. AEminiumGPU does not force developers to understand the particularities of GPU programming. Programs can be written in pure Java (and soon AEminium) but specific parts of the code are compiled to OpenCL and executed on the GPU.

AEMiniumGPU is a framework composed by a compiler and a runtime. It is available for download the following address: https://github.com/alcides/AeminiumGPUCompiler/

== AEminium at the University of Madeira ==

The organizers of FMICS'11 selected the article "Multi-Task Threaded Server: A Case Study With The Plural Tool" by Néstor Cataño and Ijaz Ahmed for submission to Science of Computer Programming (SCP). FMICS invited 7 papers in total and will select 5 of them for final publication to SCP. This article discusses the business case provided by AEMinium's industrial partner Novabase.

Follow this [http://www3.uma.pt/ncatano/aeminium/Home.html link] for more information on what the University of Madeira is doing on the AEminium project.

== AEminium source code ==
Check out [http://code.google.com/p/aeminium/ Google Code] for code and examples (under development).

Dissemination

2012-04-10T16:32:42Z

Aeminium: /* Publications */

== Publications ==

A. Fonseca, B. Cabral, "Handling Exceptions in Programs with Hidden Concurrency: New Challenges for "Old" Solutions", in ICSE'12 Workshop Proceedings, 5th International Workshop on Exception Handling (WEH.12), Zurich, Switzerland, June, 2012.

Néstor Cataño and Ijaz Ahmed, Lightweight Veriﬁcation of a Multi-Task Threaded Server: A Case Study With The Plural Tool, in Proceedings of 16th International Workshop on Formal Methods for Industrial Critical Systems (FMICS'11), Trento, Italy, August 29-30, 2011 [http://aeminium.dei.uc.pt/images/6/67/Mtts.pdf]

Nels E. Beckman, Duri Kim, and Jonathan Aldrich, An Empirical Study of Object Protocols in the Wild, in Proceedings of the European Conference on Object-Oriented Programming (ECOOP '11), 2011. [http://www.cs.cmu.edu/~aldrich/papers/aldrich-empirical-ecoop11.pdf]

Roger Wolff, Ronald Garcia, Éric Tanter, and Jonathan Aldrich, Gradual Typestate, in Proceedings of the European Conference on Object-Oriented Programming (ECOOP '11), 2011. [http://www.cs.cmu.edu/~aldrich/papers/aldrich-gradual-ecoop11.pdf]

Ligia Nistor and Jonathan Aldrich, Verifying Object-Oriented Code Using Object Propositions, in International Workshop on Aliasing, Confinement and Ownership in object-oriented programming (IWACO), 2011. [http://www.cs.cmu.edu/~aldrich/papers/nistor-iwaco11.pdf]

Joshua Sunshine, Karl Naden, Sven Stork, Jonathan Aldrich, and Éric Tanter, First-Class State Change in Plaid, To appear in Proceedings of Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA '11), 2011, [http://www.cs.cmu.edu/~aldrich/papers/plaid-oopsla11.pdf]

David Alves, Pedro Bizarro and Paulo Marques, Deadline Queries: Leveraging the Cloud to Produce On-Time Results, in Proceedings of the Fourth IEEE International Conference on Cloud Computing (CLOUD 2011), July 4-9, 2011, Washington Marriott, Washington DC, USA, [http://aeminium.dei.uc.pt/images/5/5a/Paper_cloud_2011_cr_final_v2.pdf]

Jonathan Aldrich, Ronald Garcia, Mark Hahnenberg, Manuel Mohr, Karl Naden, Darpan Saini, Sven Stork, Joshua Sunshine, Éric Tanter, and Roger Wolff,
Permission-Based Programming Languages (NIER Track), in Proceedings of the International Conference on Software Engineering (ICSE '11), New Ideas and Emerging Results Track, 2011, [http://www.cs.cmu.edu/~aldrich/papers/plaid-NIER2010.pdf]

Filipe Militão, Jonathan Aldrich, and Luís Caires, Aliasing Control with View-Based Typestate, in Proceedings of Formal Techniques for Java Like Programs (FTfJP), 2010. [http://www.cs.cmu.edu/~aldrich/papers/ftfjp2010-view.pdf]

Sven Stork, Paulo Marques, Jonathan Aldrich. Concurrency by Default: Using Permissions to Express Dataflow in Stateful Programs. Onward! Conference, Orlando, Florida, USA, October, 2009, [http://www.cs.cmu.edu/~svens/papers/onward-2009.pdf].

== Thesis ==

Alcides Fonseca, ÆminiumGPU: A CPU-GPU Hybrid Runtime for the Æminium Language, thesis submitted to the University of Coimbra for obtaining the Masters’ Degree in Informatics Engineering, September 2011 [http://aeminium.dei.uc.pt/images/7/73/Alcides_fonseca_msc_thesis.pdf]

Manuel Mohr, AEminium Compilation Theory in the Context of the Plaid Language, Diploma thesis submitted to the Karlsruhe Institute of
Technology, February 2011 [http://pp.info.uni-karlsruhe.de/~mohr/DiplomaThesisMohr.pdf]

Sven Stork, Concurrent Programming via Access Permissions, PhD Thesis Proposal, Coimbra, Portugal, September 2009, [http://www.cs.cmu.edu/~svens/papers/proposal-2009.pdf].

== Internal Presentations ==

July 2011: [http://aeminium.dei.uc.pt/images/6/6a/Presentation.pdf Pulse: Plural To EVMDD-SMC - The Compiler and Model Generator]

March 2011 at Novabase: [http://aeminium.dei.uc.pt/images/0/05/Novabase.pdf Lightweight Verification of a Multi-Task Threaded Server: A Case Study With The Plural Tool]

== Public Presentations ==

Jonathan Aldrich, Ronald Garcia, Mark Hahnenberg, Manuel Mohr, Karl Naden, Darpan Saini, Sven Stork, Joshua Sunshine, Éric Tanter, and Roger Wolff. Permission-Based Programming Languages (NIER Track). At the International Conference on Software Engineering (ICSE '11), New Ideas and Emerging Results Track, 2011 [http://aeminium.dei.uc.pt/images/9/91/Plaidpermissions-icsenier-may11.pdf Plaidpermissions-icsenier-may11.pdf]

Concurrency-Workshop 2010: [http://aeminium.dei.uc.pt/images/a/ae/AEminium-in-a-Nutshell.pdf AEminium-in-a-Nutshell.pdf]

UC/Seminar presentation January 2009: [http://aeminium.dei.uc.pt/images/1/1e/Designing-a-Concurrent-Programming-Language.pdf Designing-a-Concurrent-Programming-Language.pdf]

SSSG talk 2009: [http://aeminium.dei.uc.pt/images/a/a6/SSSG-Conurrency-by-Default.pdf SSSG-Concurrency-by-Default.pdf]

PhD-Proposal short presentation: [http://aeminium.dei.uc.pt/images/6/6c/Concurrent-Programming-via-Access-Permissions.pdf Concurrent-Programming-via-Access-Permissions.pdf]

Phd-Proposal UC: [http://aeminium.dei.uc.pt/images/f/f6/PhD-Proposal-Defense-UC.pdf PhD-Proposal-Defense-UC.pdf]

Onward 2009: [http://aeminium.dei.uc.pt/images/f/ff/Concurrency-By-Default.pdf Concurreny-By-Default.pdf]

SSSG 2008: [http://aeminium.dei.uc.pt/images/e/e2/ParallelProgrammingModels.pdf Parallel-Programming-Models.pdf]

SSSG 2008: [http://aeminium.dei.uc.pt/images/d/d5/SSSG-CurrentResearch.pdf SSSG-CurrentResearch.pdf]

DocumentationAeminiumRuntimeProfiler

2012-02-21T10:50:48Z

Aeminium: /* Running an Application */

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/username/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/username/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The ''profiler package'' contains two types of classes. The first type concerns the classes which were only created to make the process of collecting the profiling information easier. Then, in the second type, we can include all the classes that are strictly required by the JProfiler to perform its activity.
The first two classes present in this text belong tot he first type, while the other three fall in the second category.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This extra step is necessary because the JProfiler classes must use a fixed constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for instance, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime at start time and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references. In order to avoid ''null'' values (if the JProfiler starts sampling before the Runtime is fully ready), it's wise to always double check the contents of the references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measurement, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these two components responsible for filling the fields that are related to them.
Therefore, DataCollection contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will also have more than a single working thread. Besides it, there are three different types of tasks too, namely Atomic, Non-blocking and Blocking tasks. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three classes left for analysis are the ones which are required by JProfiler to collect telemetry information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider is a simple class that let's JProfiler know which are the probe classes present in the project that are going to be used for profiling. It merely contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global task activity for the scheduler and graph. By global task activity, we mean, for example, the number of completed tasks or how many tasks marked as running at a given moment.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

This second group separates by the values by each working thread, whose number is defined by the value in 'maxParallelism'.

For collecting data, the method fillTelemetryData() is executed, going through the following steps:
# Firstly, as stated before, a instance of the class DataCollection is created.
# Then, after checking if the scheduler reference is not null, we simply call the method collectData().
# At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values.
# The next step is exactly the same, but now, we will doing the profiling for the graph variables.
# At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

Our Profiler uses JProfiler method interception for controlling the time every task spend at each state. We take advantage of the fact that tasks change theirs state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), and so, we only intercept method entrances.

Firstly, we need to define all the method to intercept at the getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

Let's now take a look at the interception mechanism. To achieve the time measuring, we use a systematic and quite simple procedure, which is aided by auxiliary hashtables, one for each state a task can assume. The hashtables will hold payloads, which save the time of their creation.

At the entry of a method, we have two states to consider. The one a thread has at the moment, the old state, and another, which is the state this task will change to. We get the payload from the old state's hashtable, passing it to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a that state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the previous paragraph. This second step marks the starting time of the new state.

Naturally, this procedure is different for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T17:29:47Z

Aeminium: /* IMPORTANT NOTE */

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The ''profiler package'' contains two types of classes. The first type concerns the classes which were only created to make the process of collecting the profiling information easier. Then, in the second type, we can include all the classes that are strictly required by the JProfiler to perform its activity.
The first two classes present in this text belong tot he first type, while the other three fall in the second category.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This extra step is necessary because the JProfiler classes must use a fixed constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for instance, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime at start time and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references. In order to avoid ''null'' values (if the JProfiler starts sampling before the Runtime is fully ready), it's wise to always double check the contents of the references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measurement, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these two components responsible for filling the fields that are related to them.
Therefore, DataCollection contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will also have more than a single working thread. Besides it, there are three different types of tasks too, namely Atomic, Non-blocking and Blocking tasks. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three classes left for analysis are the ones which are required by JProfiler to collect telemetry information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider is a simple class that let's JProfiler know which are the probe classes present in the project that are going to be used for profiling. It merely contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global task activity for the scheduler and graph. By global task activity, we mean, for example, the number of completed tasks or how many tasks marked as running at a given moment.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

This second group separates by the values by each working thread, whose number is defined by the value in 'maxParallelism'.

For collecting data, the method fillTelemetryData() is executed, going through the following steps:
# Firstly, as stated before, a instance of the class DataCollection is created.
# Then, after checking if the scheduler reference is not null, we simply call the method collectData().
# At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values.
# The next step is exactly the same, but now, we will doing the profiling for the graph variables.
# At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

Our Profiler uses JProfiler method interception for controlling the time every task spend at each state. We take advantage of the fact that tasks change theirs state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), and so, we only intercept method entrances.

Firstly, we need to define all the method to intercept at the getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

Let's now take a look at the interception mechanism. To achieve the time measuring, we use a systematic and quite simple procedure, which is aided by auxiliary hashtables, one for each state a task can assume. The hashtables will hold payloads, which save the time of their creation.

At the entry of a method, we have two states to consider. The one a thread has at the moment, the old state, and another, which is the state this task will change to. We get the payload from the old state's hashtable, passing it to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a that state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the previous paragraph. This second step marks the starting time of the new state.

Naturally, this procedure is different for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T17:27:10Z

Aeminium: /* The profiler package */

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The ''profiler package'' contains two types of classes. The first type concerns the classes which were only created to make the process of collecting the profiling information easier. Then, in the second type, we can include all the classes that are strictly required by the JProfiler to perform its activity.
The first two classes present in this text belong tot he first type, while the other three fall in the second category.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This extra step is necessary because the JProfiler classes must use a fixed constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for instance, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime at start time and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references. In order to avoid ''null'' values (if the JProfiler starts sampling before the Runtime is fully ready), it's wise to always double check the contents of the references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measurement, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these two components responsible for filling the fields that are related to them.
Therefore, DataCollection contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will also have more than a single working thread. Besides it, there are three different types of tasks too, namely Atomic, Non-blocking and Blocking tasks. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three classes left for analysis are the ones which are required by JProfiler to collect telemetry information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider is a simple class that let's JProfiler know which are the probe classes present in the project that are going to be used for profiling. It merely contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global task activity for the scheduler and graph. By global task activity, we mean, for example, the number of completed tasks or how many tasks marked as running at a given moment.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

This second group separates by the values by each working thread, whose number is defined by the value in 'maxParallelism'.

For collecting data, the method fillTelemetryData() is executed, going through the following steps:
# Firstly, as stated before, a instance of the class DataCollection is created.
# Then, after checking if the scheduler reference is not null, we simply call the method collectData().
# At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values.
# The next step is exactly the same, but now, we will doing the profiling for the graph variables.
# At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

Our Profiler uses JProfiler method interception for controlling the time every task spend at each state. We take advantage of the fact that tasks change theirs state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), and so, we only intercept method entrances.

Firstly, we need to define all the method to intercept at the getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

Let's now take a look at the interception mechanism. To achieve the time measuring, we use a systematic and quite simple procedure, which is aided by auxiliary hashtables, one for each state a task can assume. The hashtables will hold payloads, which save the time of their creation.

At the entry of a method, we have two states to consider. The one a thread has at the moment, the old state, and another, which is the state this task will change to. We get the payload from the old state's hashtable, passing it to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a that state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the previous paragraph. This second step marks the starting time of the new state.

Naturally, this procedure is different for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T17:14:01Z

Aeminium: /* CountersProbe (Telemetry Data) */

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The ''profiler package'' contains two types of classes. The first type concerns the classes which were only created to make the process of collecting the profiling information easier. Then, in the second type, we can include all the classes that are strictly required by the JProfiler to perform its activity.
The first two classes present in this text belong tot he first type, while the other three fall in the second category.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This extra step is necessary because the JProfiler classes must use a fixed constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for instance, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime at start time and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references. In order to avoid ''null'' values (if the JProfiler starts sampling before the Runtime is fully ready), it's wise to always double check the contents of the references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measurement, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these two components responsible for filling the fields that are related to them.
Therefore, DataCollection contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will also have more than a single working thread. Besides it, there are three different types of tasks too, namely Atomic, Non-blocking and Blocking tasks. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three classes left for analysis are the ones which are required by JProfiler to collect telemetry information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider is a simple class that let's JProfiler know which are the probe classes present in the project that are going to be used for profiling. It merely contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global task activity for the scheduler and graph. By global task activity, we mean, for example, the number of completed tasks or how many tasks marked as running at a given moment.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

This second group separates by the values by each working thread, whose number is defined by the value in 'maxParallelism'.

For collecting data, the method fillTelemetryData() is executed, going through the following steps:
# Firstly, as stated before, a instance of the class DataCollection is created.
# Then, after checking if the scheduler reference is not null, we simply call the method collectData().
# At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values.
# The next step, is exactly the same, but now, we will doing the profiling for the graph variables.
# At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T17:13:26Z

Aeminium: /* CountersProbe (Telemetry Data) */

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The ''profiler package'' contains two types of classes. The first type concerns the classes which were only created to make the process of collecting the profiling information easier. Then, in the second type, we can include all the classes that are strictly required by the JProfiler to perform its activity.
The first two classes present in this text belong tot he first type, while the other three fall in the second category.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This extra step is necessary because the JProfiler classes must use a fixed constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for instance, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime at start time and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references. In order to avoid ''null'' values (if the JProfiler starts sampling before the Runtime is fully ready), it's wise to always double check the contents of the references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measurement, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these two components responsible for filling the fields that are related to them.
Therefore, DataCollection contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will also have more than a single working thread. Besides it, there are three different types of tasks too, namely Atomic, Non-blocking and Blocking tasks. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three classes left for analysis are the ones which are required by JProfiler to collect telemetry information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider is a simple class that let's JProfiler know which are the probe classes present in the project that are going to be used for profiling. It merely contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global task activity for the scheduler and graph. By global task activity, we mean, for example, the number of completed tasks or how many tasks marked as running at a given moment.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

This second group separates by the values by each working thread, whose number is defined by the value in 'maxParallelism'.

For collecting data, the method fillTelemetryData() is executed, going through the following steps:
# Firstly, as stated before, a instance of the class DataCollection is created.
# Then, after checking if the scheduler reference is not null, we simply call the method collectData().
# At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values.
# The next, is exactly the same, but now, we will doing the profiling for the graph variables.
# At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T17:12:29Z

Aeminium: /* The profiler package */

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The ''profiler package'' contains two types of classes. The first type concerns the classes which were only created to make the process of collecting the profiling information easier. Then, in the second type, we can include all the classes that are strictly required by the JProfiler to perform its activity.
The first two classes present in this text belong tot he first type, while the other three fall in the second category.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This extra step is necessary because the JProfiler classes must use a fixed constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for instance, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime at start time and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references. In order to avoid ''null'' values (if the JProfiler starts sampling before the Runtime is fully ready), it's wise to always double check the contents of the references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measurement, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these two components responsible for filling the fields that are related to them.
Therefore, DataCollection contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will also have more than a single working thread. Besides it, there are three different types of tasks too, namely Atomic, Non-blocking and Blocking tasks. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three classes left for analysis are the ones which are required by JProfiler to collect telemetry information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider is a simple class that let's JProfiler know which are the probe classes present in the project that are going to be used for profiling. It merely contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global task activity for the scheduler and graph. By global task activity, we mean, for example, the number of completed tasks or how many tasks marked as running at a given moment.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

This second group separates by the values by each working thread, whose number is defined by the value in 'maxParallelism'.

For collecting data, the method fillTelemetryData() is executed, going through the following steps:
# As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData().
# At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
#At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T17:11:11Z

Aeminium: /* The profiler package */

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The ''profiler package'' contains two types of classes. The first type concerns the classes which were only created to make the process of collecting the profiling information easier. Then, in the second type, we can include all the classes that are strictly required by the JProfiler to perform its activity.
The first two classes present in this text belong tot he first type, while the other three fall in the second category.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This extra step is necessary because the JProfiler classes must use a fixed constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for instance, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime at start time and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references. In order to avoid ''null'' values (if the JProfiler starts sampling before the Runtime is fully ready), it's wise to always double check the contents of the references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measurement, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these two components responsible for filling the fields that are related to them.
Therefore, DataCollection contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will also have more than a single working thread. Besides it, there are three different types of tasks too, namely Atomic, Non-blocking and Blocking tasks. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three classes left for analysis are the ones which are required by JProfiler to collect telemetry information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider is a simple class that let's JProfiler know which are the probe classes present in the project that are going to be used for profiling. It merely contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global task activity for the scheduler and graph. By global task activity, we mean, for example, the number of completed tasks or how many tasks marked as running at a given moment.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

This second group separates by the values by each working thread, whose number is defined by the value in 'maxParallelism'.

For collecting data, the method fillTelemetryData() is executed, going through the following steps:
1. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData().
2. At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T17:05:35Z

Aeminium: /* JProfiler Classes */

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The ''profiler package'' contains two types of classes. The first type concerns the classes which were only created to make the process of collecting the profiling information easier. Then, in the second type, we can include all the classes that are strictly required by the JProfiler to perform its activity.
The first two classes present in this text belong tot he first type, while the other three fall in the second category.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This extra step is necessary because the JProfiler classes must use a fixed constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for instance, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime at start time and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references. In order to avoid ''null'' values (if the JProfiler starts sampling before the Runtime is fully ready), it's wise to always double check the contents of the references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measurement, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these two components responsible for filling the fields that are related to them.
Therefore, DataCollection contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will also have more than a single working thread. Besides it, there are three different types of tasks too, namely Atomic, Non-blocking and Blocking tasks. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three classes left for analysis are the ones which are required by JProfiler to collect telemetry information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T17:05:12Z

Aeminium: /* JProfiler Classes */

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The ''profiler package'' contains two types of classes. The first type concerns the classes which were only created to make the process of collecting the profiling information easier. Then, in the second type, we can include all the classes that are strictly required by the JProfiler to perform its activity.
The first two classes present in this text belong tot he first type, while the other three fall in the second category.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This extra step is necessary because the JProfiler classes must use a fixed constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for instance, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime at start time and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references. In order to avoid ''null'' values (if the JProfiler starts sampling before the Runtime is fully ready), it's wise to always double check the contents of the references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measurement, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these two components responsible for filling the fields that are related to them.
Therefore, DataCollection contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will also have more than a single working thread. Besides it, there are three different types of tasks too, namely Atomic, Non-blocking and Blocking tasks. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three classes left for analyzis are the ones which are required by JProfiler to collect telemetry information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T17:03:57Z

Aeminium:

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The ''profiler package'' contains two types of classes. The first type concerns the classes which were only created to make the process of collecting the profiling information easier. Then, in the second type, we can include all the classes that are strictly required by the JProfiler to perform its activity.
The first two classes present in this text belong tot he first type, while the other three fall in the second category.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This extra step is necessary because the JProfiler classes must use a fixed constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for instance, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime at start time and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references. In order to avoid ''null'' values (if the JProfiler starts sampling before the Runtime is fully ready), it's wise to always double check the contents of the references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measurement, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these two components responsible for filling the fields that are related to them.
Therefore, DataCollection contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will also have more than a single working thread. Besides it, there are three different types of tasks too, namely Atomic, Non-blocking and Blocking tasks. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three other classes that also belong to the profiler package are the ones which are required by JProfiler to collect telemetries information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T16:59:02Z

Aeminium:

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The ''profiler package'' contains two types of classes. The first type concerns the classes which were only created to make the process of collecting the profiling information easier. Then, in the second type, we can include all the classes that are strictly required by the JProfiler to perform its activity.
The first two classes present in this text belong tot he first type, while the other three fall in the second category.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This is necessary because the JProfiler classes must follow a strict constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for the example, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measuring, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these components responsible for filling with values the fields that are related to them.
Therefore, it contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will have more than a single working thread. Also, there is also three different types of tasks, namely Atomic, Non-blocking and Blocking. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three other classes that also belong to the profiler package are the ones which are required by JProfiler to collect telemetries information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T16:55:33Z

Aeminium: /* Running an Application */

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The first two classes are regular Java classes, which were created just to make easier the process of collecting the profiling information.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This is necessary because the JProfiler classes must follow a strict constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for the example, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measuring, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these components responsible for filling with values the fields that are related to them.
Therefore, it contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will have more than a single working thread. Also, there is also three different types of tasks, namely Atomic, Non-blocking and Blocking. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three other classes that also belong to the profiler package are the ones which are required by JProfiler to collect telemetries information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T16:55:07Z

Aeminium: /* Running an Application */

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on the online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The first two classes are regular Java classes, which were created just to make easier the process of collecting the profiling information.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This is necessary because the JProfiler classes must follow a strict constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for the example, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measuring, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these components responsible for filling with values the fields that are related to them.
Therefore, it contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will have more than a single working thread. Also, there is also three different types of tasks, namely Atomic, Non-blocking and Blocking. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three other classes that also belong to the profiler package are the ones which are required by JProfiler to collect telemetries information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T16:54:46Z

Aeminium: /* Running an Application */

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on the online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].
 

== The profiler package ==

The first two classes are regular Java classes, which were created just to make easier the process of collecting the profiling information.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This is necessary because the JProfiler classes must follow a strict constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for the example, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measuring, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these components responsible for filling with values the fields that are related to them.
Therefore, it contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will have more than a single working thread. Also, there is also three different types of tasks, namely Atomic, Non-blocking and Blocking. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three other classes that also belong to the profiler package are the ones which are required by JProfiler to collect telemetries information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T16:54:29Z

Aeminium: /* Running an Application */

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on the online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652, config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

 

== The profiler package ==

The first two classes are regular Java classes, which were created just to make easier the process of collecting the profiling information.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This is necessary because the JProfiler classes must follow a strict constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for the example, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measuring, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these components responsible for filling with values the fields that are related to them.
Therefore, it contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will have more than a single working thread. Also, there is also three different types of tasks, namely Atomic, Non-blocking and Blocking. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three other classes that also belong to the profiler package are the ones which are required by JProfiler to collect telemetries information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T16:53:58Z

Aeminium:

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on the online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652,config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

 

== The profiler package ==

The first two classes are regular Java classes, which were created just to make easier the process of collecting the profiling information.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This is necessary because the JProfiler classes must follow a strict constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for the example, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measuring, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these components responsible for filling with values the fields that are related to them.
Therefore, it contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will have more than a single working thread. Also, there is also three different types of tasks, namely Atomic, Non-blocking and Blocking. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three other classes that also belong to the profiler package are the ones which are required by JProfiler to collect telemetries information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-18T16:48:28Z

Aeminium:

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Æminium Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime, so you must download it before starting any profiling tests.
Besides reading the documentation present in this page, also consider consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered here.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

This will allow you monitoring the Runtime activity on the online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

As for offline mode, use the following command:

java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652,config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

 

== The profiler package ==

The first two classes are regular Java classes, which were created just to make easier the process of collecting the profiling information.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This is necessary because the JProfiler classes must follow a strict constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for the example, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measuring, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these components responsible for filling with values the fields that are related to them.
Therefore, it contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will have more than a single working thread. Also, there is also three different types of tasks, namely Atomic, Non-blocking and Blocking. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three other classes that also belong to the profiler package are the ones which are required by JProfiler to collect telemetries information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-12T23:04:36Z

Aeminium: /* Preparing the ground */

== IMPORTANT NOTE ==
This page is still under construction, so the text might eventually be reviewed.

== Preparing the ground ==

=== Downloads ===
The Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime.
Also, considering consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered in this page.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/alcides/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

 

== The profiler package ==

The first two classes are regular Java classes, which were created just to make easier the process of collecting the profiling information.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This is necessary because the JProfiler classes must follow a strict constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for the example, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measuring, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these components responsible for filling with values the fields that are related to them.
Therefore, it contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will have more than a single working thread. Also, there is also three different types of tasks, namely Atomic, Non-blocking and Blocking. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three other classes that also belong to the profiler package are the ones which are required by JProfiler to collect telemetries information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-12T22:59:41Z

Aeminium: /* TaskDetailsProbe (Method Interception) */

== Preparing the ground ==

=== Downloads ===
The Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime.
Also, considering consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered in this page.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/alcides/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

 

== The profiler package ==

The first two classes are regular Java classes, which were created just to make easier the process of collecting the profiling information.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This is necessary because the JProfiler classes must follow a strict constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for the example, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measuring, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these components responsible for filling with values the fields that are related to them.
Therefore, it contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will have more than a single working thread. Also, there is also three different types of tasks, namely Atomic, Non-blocking and Blocking. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three other classes that also belong to the profiler package are the ones which are required by JProfiler to collect telemetries information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe (Telemetry Data) ===

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe (Method Interception)===

The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.

Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.

Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.

At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.

Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.

DocumentationAeminiumRuntimeProfiler

2012-02-12T22:52:06Z

Aeminium: /* TaskDetailsProbe (Method Interception) */

DocumentationAeminiumRuntimeProfiler

2012-02-12T22:32:59Z

Aeminium: /* TaskDetailsProbe */

DocumentationAeminiumRuntimeProfiler

2012-02-12T22:32:44Z

Aeminium: /* CountersProbe */

DocumentationAeminiumRuntimeProfiler

2012-02-12T22:32:27Z

Aeminium: /* CountersProbe */

== Preparing the ground ==

=== Downloads ===
The Profiler uses the [http://www.ej-technologies.com/products/jprofiler/overview.html JProfiler framework] to collect and manage all the information concerning the performance of the Æminium Runtime.
Also, considering consulting the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation] whenever you have a doubt which isn't covered in this page.

=== Running an Application===
To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/alcides/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''

* The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

:* In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

* The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

 

== The profiler package ==

The first two classes are regular Java classes, which were created just to make easier the process of collecting the profiling information.

=== AeminiumProfiler ===

This class was created so we could statically refer the scheduler and the graph. This is necessary because the JProfiler classes must follow a strict constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for the example, the Runtime as an argument to the probe providers.
To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references.

=== DataCollection ===

The DataCollection works like a structure that will hold all the variables to profile. At each measuring, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these components responsible for filling with values the fields that are related to them.
Therefore, it contains the following variables:

===== Scheduler variables =====
* public int noOccupiedQueues;
* public int [] taskInNonBlockingQueue;
* public int taskInBlockingQueue;
* public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable.
In most cases, we will have more than a single working thread. Also, there is also three different types of tasks, namely Atomic, Non-blocking and Blocking. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

===== Graph variables =====
* public int noTasksCompleted[];
* public int noUnscheduledTasks;
* public int noWaitingForChildrenTasks;
* public int noWaitingForDependenciesTasks;
* public int noTasksWaitingInQueue;
* public int noRunningTasks;
* public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.
----

=== JProfiler Classes===

The three other classes that also belong to the profiler package are the ones which are required by JProfiler to collect telemetries information, as well as handle method interception.

=== AeminiumProbeProvider ===

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

=== CountersProbe ===

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3 metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4 metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5 metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6 metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables.
At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

=== TaskDetailsProbe ===

The class

DocumentationAeminiumRuntimeProfiler

2012-02-12T17:47:28Z

Aeminium: /* AeminiumProbeProvider */

DocumentationAeminiumRuntimeProfiler

2012-02-12T17:43:34Z

Aeminium: /* Downloads */